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

# Integration Architecture

> Decide what your application, buyer agent, and Interchange should each own in an end-to-end buying workflow.

If your product creates advertising content and also needs to buy media, it can
bring a finished creative from its own pipeline or, when available, use a
connected creative engine to build one. Both paths should meet at the same
handoff: durable assets, a creative manifest, an exact approved version, and
the campaign that will use it. Connect the application—or a buyer agent it
operates—to Interchange for the buying loop. Interchange is the multi-seller
transaction layer; it is not necessary to build and maintain a separate
adapter for every seller.

This page describes ways to compose a buying workflow. It does not treat every
MCP client as a buyer agent. Claude or ChatGPT can call the same tools in an
authorized user's interactive session without becoming software installed in
the buyer organization.

## An MCP client is not automatically a buyer agent

Registration is about durable software identity and governance, not which V3
calls the software makes or how intelligent it is.

| Operating model        | What it is                                                                                                                                                                                  | Buyer-agent registration                                                     |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| Interactive MCP client | Claude, ChatGPT, or another client calls Interchange in an authorized user's session. The model can guide the whole workflow, but it has no independent buyer-agent principal or lifecycle. | Not required                                                                 |
| Buyer application      | Application code calls Interchange using supported user or application authentication and owns its product workflow.                                                                        | Not required unless the software needs to act as its own installed principal |
| External buyer agent   | Customer-operated software has its own durable principal, credentials, exact advertiser grants, lifecycle, and machine notifications.                                                       | Required                                                                     |
| Hosted buyer agent     | The same governed organization resource, with its runtime operated by Interchange.                                                                                                          | Required, but hosted creation is not available in the V3 preview             |

If a user tells Claude what to buy and Claude calls V3 under that user's
connection, they are using an agent-assisted Interchange workflow. They have
not built or installed a buyer agent. Register an external buyer agent only
when the software needs an identity, authority, and lifecycle separate from a
human's interactive session.

“Light” and “heavy” are useful implementation descriptions, not product
identity classes. A light agent may keep only durable workflow checkpoints and
Interchange object/report references; a heavier runtime may also orchestrate
creative pipelines and external data tools. Either becomes a buyer agent only
through the registered-principal boundary above.

## Recommended boundary

| Owner                                     | Responsibilities                                                                                                                                                                         |
| ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Your application                          | Product UX, users and permissions, customer approval policy, and any creative pipeline or provider integrations you choose to own                                                        |
| Your MCP client or buyer agent, when used | Turn intent into typed calls, drive the selected creative path, compare inventory, explain recommendations, and resume from durable checkpoints when its operating model provides them   |
| Interchange                               | Canonical advertiser, asset, creative, campaign, buying, and reporting state; seller eligibility; proposal fan-out; execution; downstream creative handoff; and seller-reported delivery |

Your MCP client, application, or registered buyer agent should call the single
Interchange V3 MCP endpoint. It should not call each seller independently or
recreate seller-specific commercial, authorization, execution, and reporting
adapters underneath Interchange.

## Two creative paths, one handoff

Design the workflow so the creative pipeline is replaceable. A customer should
not have to adopt an orchestrated generation experience to use Interchange for
assets, creative manifests, validation, buying, and delivery.

| Path                      | How it works                                                                                                                                                                                | Best fit                                                                                             |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| Bring your own pipeline   | Your application or agent calls its preferred generation tools directly, performs any advanced edits or transformations there, and hands the approved asset and its metadata to Interchange | Teams with an existing creative stack, custom orchestration, or provider-specific workflows          |
| Managed creative pipeline | A connected creative engine plans, generates, evaluates, refines, and prepares renditions before the selected result enters the same asset and creative handoff                             | Teams that want an opinionated workflow, fewer integrations, and reusable quality and approval gates |

The managed path can add value through format-aware planning, provenance,
evaluation, rendition preparation, approval checkpoints, and consistent cost
and usage records. Those conveniences must remain optional. The portable
contract is the asset plus creative manifest—not the pipeline that produced
them.

In a future v3 surface, creative engines can be discoverable counterparties in
the same way sellers are discoverable today. That does not imply every engine
must be called through Interchange. A buyer-controlled agent may call a
provider's API or MCP tools directly and then register the result through the
portable handoff.

## What is available now

| Capability                                                                        | v3 preview today                                                                                                                                                                                                            |
| --------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Use Claude, ChatGPT, or another interactive MCP client                            | Available. Connect it to `https://api.interchange.io/mcp/v3` and use the current `tools/list` schemas. This does not register a buyer agent.                                                                                |
| Use a customer-built application                                                  | Available through the same V3 MCP endpoint, using supported authentication. It remains an application integration unless registered as an independent buyer-agent principal.                                                |
| Create campaigns, discover inventory, stage media buys, launch, and read delivery | Available within the buyer workflow and the documented preview limits.                                                                                                                                                      |
| Bring a finished image, video, audio, HTML, VAST, or text asset                   | Available through `save_creative` using a supported HTTPS URL or inline base64 data URL. The content must already exist; v3 does not generate it.                                                                           |
| Generate or revise creative inside the v3 workflow                                | Not available. Keep generation in your application or creative provider and hand the finished asset to Interchange.                                                                                                         |
| Discover and connect creative engines beside sellers                              | Not available in the public v3 catalog. Treat this as a design direction, not a callable surface, until it appears in `tools/list`.                                                                                         |
| Ask Interchange to host and run the entire customer-defined workflow              | Not available in the v3 preview. The integrating application or its external agent owns orchestration and recovery.                                                                                                         |
| Connect and govern an external buyer agent                                        | Available through the buyer console and stable v2 administration API: register identity-only credentials, grant exact advertiser access, and configure machine notifications. These controls grant no authority implicitly. |
| Manage or create a hosted agent as a v3 `buyer_agent` resource                    | Not currently in the public v3 catalog. Do not design against the noun or hosted execution until they appear in `tools/list`.                                                                                               |

v3 is MCP-only. If your server requires REST rather than acting as an MCP
client, use the stable v2 REST API against the same Interchange account data.

## Application, agent, or both?

For a production product today, use a hybrid architecture:

1. Let an application-controlled durable store own IDs, idempotency keys,
   retries, customer approvals, workflow checkpoints, and immutable
   Interchange report references. A buyer agent may drive those checkpoints,
   but one model turn should not be their only record. Keep canonical delivery
   facts, aggregation, and reporting results in Interchange instead of building
   a second reporting warehouse in the orchestrator.
2. Use an agent for judgment-heavy steps such as turning a goal into a brief,
   comparing proposals, explaining tradeoffs, and suggesting an allocation.
3. Require an explicit application-controlled confirmation before the
   `save_campaign` call that makes a campaign active.

Pure application orchestration is a good fit when every transition is
deterministic. An interactive Claude or ChatGPT connection is a good fit for a
human-guided workflow and requires no buyer-agent registration. A registered,
customer-operated external buyer agent is appropriate when the software must
continue independently with its own identity, grants, lifecycle, and machine
notifications. All three use the same V3 buying tools; Interchange remains the
execution layer.

Do not rely on one long model turn to own the workflow. Proposal requests,
creative reviews, and delivery happen asynchronously. Persist the returned
advertiser, asset, creative, campaign, proposal, product-query, media-buy, and
revision identifiers in an application or agent control plane, then resume
from fresh `get` and `search` results. A future hosted buyer agent can provide
that control plane without becoming a second reporting warehouse.

## Example: AI-created radio spot to media buy

The following workflow works even though Interchange does not currently
generate the radio creative. A user can drive it interactively from Claude, an
application can encode it deterministically, or a registered external buyer
agent can run it under its own grants. The buying calls are the same; identity,
durability, and governance are not.

1. **Choose the creative path.** Today, create the spot outside Interchange:
   your application or agent calls its chosen audio-generation provider and
   stores the master asset and provenance. A future managed creative pipeline
   should produce the same handoff without changing the remaining buying
   steps.
2. **Collect customer content approval.** Record who approved which immutable
   creative version. This is your product's approval and does not replace a
   seller or ad-server creative review.
3. **Open the buying workspace.** Call `get_status`, create or select the
   advertiser, and use `save_campaign` to create a draft with the brief,
   flight, and budget.
4. **Discover suitable inventory.** Call `request_proposals`, poll the same
   execution to a terminal result, follow every result cursor, and present the
   returned proposals or products. Preserve qualified IDs exactly.
5. **Prepare the delivery-ready rendition.** Check the selected product's
   accepted formats. If the approved master does not already satisfy them,
   create a compliant rendition outside Interchange and approve that exact
   version. Attach its HTTPS URL or supported inline data URL with
   `save_creative`, using `assetType: "AUDIO"`.
6. **Stage the buy.** Call `save_media_buy` with the selected qualified
   proposal or product identities and allocation. This creates draft buying
   state; it does not spend or launch.
7. **Review readiness.** Use `get` on the campaign and media buys, including
   creative detail where offered, or open `open_campaign_receipt` in an MCP
   Apps host. Resolve format, creative-review, funding, or seller-readiness
   blockers before launch.
8. **Confirm and launch.** Preview `save_campaign` with
   `desiredPhase: "active"` and an idempotency key, show the returned budget,
   flight, and staged buys to the authorized user, then send a second call with
   `confirmLaunch: true`, the returned revision, and its own idempotency key.
9. **Report.** Query `get_delivery` for explicit date ranges, metrics, and
   dimensions. This is seller-reported delivery; it is not independent buyer
   measurement or proof of billing finality.

If the product insists on creating and approving the finished spot before
inventory selection, treat that file as a master. Inventory can impose a
different duration, codec, bitrate, channel layout, or other format constraint,
so the workflow may still need a destination-ready rendition and a second
approval before attachment.

## Keep the approvals separate

| Decision                                     | Owner                                              | What it authorizes                                                 |
| -------------------------------------------- | -------------------------------------------------- | ------------------------------------------------------------------ |
| Content approval                             | Your customer workflow                             | This exact spot may proceed into buying                            |
| Inventory and allocation approval            | Your application or buyer agent, under your policy | These returned products or proposals may be staged                 |
| Storefront and source-system creative review | Seller and destination system                      | The attached rendition is accepted for the selected delivery route |
| Launch confirmation                          | An authorized buyer                                | The reviewed draft may become active and execute                   |

Never infer one decision from another. In particular, a customer-approved spot
can still fail destination format validation or seller review, and a staged
media buy is not evidence that the campaign has launched.

## Related

* [Buyer workflows](/v2/setup/v3/buyer-workflows) — request and response details
* [v3 tool catalog](/v2/setup/v3/tool-reference) — current tool families
* [Creative approval](/v2/buyer/creatives/approval) — downstream review gates
* [Manage buyer agents](/v2/setup/buyer-agent-credentials) — external-agent identity, access, notifications, and readiness
* [v3 limitations](/v2/setup/v3/limitations) — preview gaps and v2 fallbacks