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 returnsbodyPruned: 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
Useorigin.kind before interpreting a failure:
sandbox_testcalls 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_demandcalls 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.
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.