> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apostra.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Build with Apostra

> Connect agents and applications to Apostra with MCP or REST.

For a new integration, start with [Build with Apostra](/v3/overview) and the
[V3 connection quickstart](/v3/quickstart). You can build a marketing assistant,
advertising agent, seller integration, automation, or reporting service.

This section keeps the supported V2 MCP and REST references available for
existing integrations and operations that require direct HTTP requests.

## Apostra REST paths

New V2 assistant integrations should use the `/api/v2/apostra` path family.
It is the canonical name for the same authenticated assistant capability that
remains available at `/api/v2/murph` for existing clients. Both families use
the same authorization, rate limits, conversation identity, streaming
behavior, and error responses; the API does not redirect requests between
them.

Use the canonical prefix with the route documented on the Murph API reference,
for example:

```text theme={null}
POST /api/v2/apostra/chat
POST /api/v2/apostra/chat/stream
GET  /api/v2/apostra/conversations
```

The full route set, including conversations, preferences, confirmations, and
assistant health, is available under both prefixes. Existing integrations can
continue using the documented `/api/v2/murph/*` paths unchanged during the
compatibility period. A complete migration guide, including the observation
window and retirement criteria, will be published before any retirement is
proposed.

## Apostra MCP endpoints

New MCP integrations should connect to `/mcp/v2/apostra` or its stable
equivalent `/mcp/apostra`. These endpoints advertise `ask_apostra` and Apostra
resource URIs only. Existing `/mcp/v2/murph` and `/mcp/murph` connections
remain direct, non-redirecting compatibility endpoints that advertise
`ask_murph` and the legacy resource URIs only.

Both endpoint families require the same authentication and OAuth protected
resource metadata. Keep the endpoint and tool name from the same family in a
connection configuration; do not switch a live connection between them as part
of a request retry.

<CardGroup cols={2}>
  <Card title="Connect an AI agent" icon="message-bot" href="/v2/quickstart">
    Connect Claude, ChatGPT, Cursor, or another MCP client in a few minutes.
  </Card>

  <Card title="Authenticate" icon="key" href="/v2/authentication">
    Choose OAuth for interactive agents or a user-owned API key for
    automation.
  </Card>

  <Card title="Build a buyer integration" icon="user" href="/v2/buyer-api-reference">
    Create advertisers and campaigns, discover products, and read delivery.
  </Card>

  <Card title="Build a seller integration" icon="store" href="/v2/storefront-api-reference">
    Configure a Seller Account, connect inventory sources, and operate demand.
  </Card>
</CardGroup>

## Choose an API version

The **Build software** tab starts with V3. Use its version picker to find V2
compatibility references. V3 MCP and supported V2 REST operate on the same
account data; their available operations differ.

<Note>
  Selecting V3 documentation does not migrate an integration or change your
  account permissions. Existing V2 integrations keep working.
</Note>

Read [V3 availability and compatibility](/v3/overview#availability-and-existing-integrations)
and the [current limitations](/v2/setup/v3/limitations) before choosing an
operation. Use the live `tools/list` schemas for the connected account.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.