Skip to main content
Three read-only surfaces answer the operating questions “what buys do I have, where is this one stuck, and what needs attention” — without a ticket and without platform support looking at a database. Each is available as a REST endpoint and as an in-chat surface (ask Murph, or open it from the rail’s Operate section). All examples use the storefront base URL:
Authenticate every request with Authorization: Bearer $SCOPE3_API_KEY.

​
Recover a failed GAM order safely

If GAM created an order but line-item trafficking failed, Pending Operations shows a separate cleanup task. Interchange uses ESA’s structured cleanup result; it never interprets vendor exception text or exposes GAM credentials.
  • If ArchiveOrders is missing, grant it in GAM and re-check, or archive the order manually.
  • If authentication expired, reconnect the ad-server connection before re-checking.
  • Review and archive appears when cleanup is verified retryable. Permission and authentication failures instead offer a confirmation-gated re-check, and archive proceeds only if the repeated safety check passes.
  • Unknown or unsafe orders require GAM review and cannot be archived from Interchange.
Only storefront account admins can resolve these tasks. Archiving requires explicit confirmation naming the GAM order, and ESA repeats every safety check immediately before archiving. An already-archived response completes the task. Marking an order manually cleaned requires the matching order ID and an audit note; it is recorded distinctly and never claims ESA archived it.

​
Media buys — every buy on the storefront

GET /media-buys returns every buy forwarded across connected sources plus buys managed directly by an ad-server source. The API retains kind: routed | esa as legacy wire values; those values describe implementation provenance, not campaign mode or settlement. Filter by status, buyerCustomerId, sourceId, or flight-start window. The default sort is urgency: buys still waiting on someone whose flight starts within 48 hours (or has already started) come first, ordered by flight start; everything else follows newest-first. Each row carries:

​
Per-buy timeline — what was sent, when, and where it is stuck

GET /media-buys/{mediaBuyId}/timeline is the seller-scoped projection of the buy’s exchange record. Stages follow the exchange lifecycle, failure branches included:
Update exchanges reuse the same stages. Inbound source webhooks appear as evidence inside stages, never as a stage of their own — many sources never send webhooks, so their absence means nothing. The screened stage is reserved for the acceptance-policy pre-screen record and is not emitted today; do not wait for it. What you can see, and what you cannot. The forwarded payload is yours to inspect — you are the counterparty to that message — minus platform-internal fields: webhook/push-notification configuration and any signing or credential material are removed server-side. Platform-internal diagnostics (resolution cache internals, worker polling state, cross-tenant audit entries) never appear; failures surface as structured error codes with a recovery class instead. A payload shown as {"pruned": true} means retention removed the stored bytes (payload bodies are kept for 90 days; the slim event record is kept indefinitely). Each source leg carries a trafficker-grade summary of the request (flight, budget, packages, targeting dimensions) with the raw JSON behind a disclosure.

​
Whose reference to quote to whom

Every leg carries two references, and they are for different counterparties: While a source is still moderating (no upstream buy exists yet), their task id is the handle; once accepted, their media-buy id is.

​
Pending operations — everything waiting on someone

GET /pending-operations returns the union of work in flight, grouped; a group appears only when it is non-empty:
  • approvals — media buys (creates and updates) waiting on your review.
  • creativeReviews — creatives waiting on your review.
  • failedForwards — approved buys that could not be sent to their source, grouped by structured error code so a source outage reads as one row, not N. Each group and item carries its gated action (below).
  • awaitingSource — buys a source accepted asynchronously and is still moderating, each with “waiting since” and the source’s task id.
  • sourceDegradations — seller-owned source-health diagnoses: an ad-server or sales-agent source you operate that is degraded, each with its severity (blocking, attention, or advisory) and a one-line summary. Only diagnoses you own appear — an issue Scope3 or a vendor must fix never shows up as your task. Each row links to the source diagnostics surface scoped to that source.
  • gamCleanups — failed GAM order cleanups that require an operator decision. The Page offers automatic archive only when the server marks the cleanup safe; recording a manual cleanup requires a note.
The same Page works in Interchange, Claude, ChatGPT, and other MCP-app hosts. Its buttons open the exact portable Approvals, timeline, retry, or source-diagnostics surface directly—there is no generated chat prompt or second assistant turn. GAM cleanup is a two-step human confirmation inside the Page and uses an app-only commit that is not exposed to the model.

​
Recovery classes: why some failures have no retry

Every forwarding failure carries a recovery class, and the class — not the operator’s optimism — decides which action is offered: A transient failure whose retry window has lapsed is treated as terminalized and also becomes escalate-only.
If your source consistently produces transient timeout failures on create_media_buy or update_media_buy — visible in source diagnostics and as persistent failedForwards here — the long-term fix is to implement AdCP asynchronous acceptance on your sales agent. Return a submitted response (with a stable task_id) immediately when the platform’s request arrives, complete the work out-of-band, then POST the result to the push_notification_config webhook URL included in the original request. This decouples your processing time from the platform’s call timeout and eliminates the failure class entirely.See the AdCP async operations reference for the protocol and payload details. Contact your operator or Scope3 support to discuss implementation.

​
Transition notifications

You do not have to keep this surface open: a forward failure on an approved buy and a source-moderation wait that ages past its deadline each push one notification to your storefront’s notification stream (in-app, email, Slack — per your delivery settings). These fire on the transition only, never repeatedly, and carry the error code and recovery class.

​
Task reference

List media buys

GET /media-buys — every buy across the storefront and connected sources, urgency-sorted

Get a buy's timeline

GET /media-buys/{mediaBuyId}/timeline — the seller-scoped exchange record

List pending operations

GET /pending-operations — everything waiting on someone

Retry a failed forward

POST /media-buy-approvals/{mediaBuyId}/retry-forward — transient, non-terminalized failures only