Skip to main content
Apostra agent debug calls show recent AdCP activity for storefront inventory sources backed by third-party sales agents. Use this endpoint when you need to understand what Apostra sent to a source, what the source returned, and whether the call came from a sandbox test run or live buyer demand. These rows describe observed AdCP calls. For external sales-agent sources, do not treat an empty or failed component cache as the same evidence as a failed live passthrough call. Cache diagnostics are about whether Apostra can reuse raw products/components for merchandising; debug-call rows are about calls that actually went to the source. The response also includes transportRequests, a bounded and redacted 30-day ledger of outbound transport evidence. calls remains the logical ADCP activity summary, so the two counts need not match. For media-buy mutations, groupId identifies the parent application operation and debugId identifies a child SDK session. physicalRequestCount counts outbound protocol attempts; logicalOperationCount counts accepted operation envelopes. Calls to the sales agent Apostra runs for an ad server source are eligible for transport evidence; those rows have a null destinationOrigin because the request goes to an Apostra-internal service. Transport evidence can be incomplete: under heavy storage load Apostra drops rows rather than slow down live requests, so a missing row does not prove that no request was sent. An operation stage of mutation_not_dispatched means Apostra stopped the operation locally. It does not mean the remote Agent rejected the request, and it does not prove the remote state is unchanged. A later authoritative read is required to establish that state.
This endpoint is available only when Apostra is enabled for the caller’s account.
Calls are an account-wide feed unless you pass sourceId. Always pass the exact Inventory Source ID before treating results as evidence for one Source; an unfiltered response is not Source-scoped.

Endpoint

GET /api/v2/murph/agent-debug-calls

Request

curl

Parameters

Response

Transport attempts

transportRequests is optional while API and UI deployments roll out independently. Current API responses include it, but clients must continue to work when an older response does not. It is additive to calls; it does not change the logical call history. When transportRequests.unavailable is true, the transport-ledger lookup was unavailable. The calls array is still returned, and the transport counts and requests array are empty. Retry the request later if you need transport attempt evidence. The authorised REST response and Diagnostics Calls UI can include captured transport detail, such as request and response headers or bodies. Treat those fields as diagnostic records for authorised operators. Apostra’s tool response uses only structural transport metadata and does not send those captured values into model context.

Retention

Apostra keeps every call indefinitely: its IDs, status, outcome codes and debug metadata (debug ID, trace, timing and HTTP status) stay available to point lookups by task, debug or correlation ID. The request and response bodies are pruned once a call is 90 days old. A pruned call returns bodyPruned: true, and the Diagnostics Calls view says the bodies were pruned after 90 days instead of showing an empty exchange. Account sync requests are the exception: Apostra keeps their bodies, because it reads which brand each seller account was synced with when it syncs that account again. Transport attempts (transportRequests) follow their own retention, given in transportRequests.retentionDays.

Provenance

Use origin.kind before interpreting a failure:
  • sandbox_test calls were created by a technical validation flow. A failed sandbox call usually means the source or adapter needs setup, protocol, or credential work before launch.
  • live_demand calls were not matched to Apostra sandbox test metadata. Treat them as actual demand or other non-test traffic unless you have separate evidence that the caller was testing manually.
When origin.kind is sandbox_test, initiatorEmail identifies the redacted test-run user when that user is available. When the test-run join is not available, Apostra falls back to the redacted activity-row user email.

Errors

  • 400 VALIDATION_ERROR — invalid query parameter.
  • 401 UNAUTHORIZED — missing or invalid bearer token.
  • 403 FORBIDDEN — Apostra is not enabled for the caller’s account.
See Errors for the full error contract.