Skip to main content
Begin with the media buy’s current phase, latest failure, approval state, and source or seller evidence. Preserve structured error codes and recovery fields; do not infer a successful transition from an HTTP or MCP transport success. The troubleshooting procedure is shared with people operating the same buy in Apostra. It explains each lifecycle checkpoint, the evidence to collect, and when support needs to become involved.

Open the troubleshooting guide

Follow the canonical media-buy diagnosis procedure.

​
Apostra support trace

Apostra support operators can open the internal stitched trace for any media-buy identifier:
Include buyerCustomerId whenever a storefront media-buy identifier is buyer-scoped or could be reused by more than one buyer. Without that scope, an ambiguous identifier returns a conflict instead of guessing which transaction to expose. Keep the same parameter when fetching one event with eventId. To read what a seller said about one creative, add creativeId (the creative’s id as it was sent to the seller) and, optionally, sourceId to narrow to one seller:
The response is creativeSyncExchange: up to ten ledger rows for that creative in the buy, newest first. A request_sent row holds what Apostra sent, a response_received row holds the seller’s reply, and a precondition_failed row means Apostra refused before sending. truncated says more rows matched, and redactedPaths lists the credential-bearing fields removed from the payloads. An empty events list means the ledger holds no row for that creative in this buy. Use either creativeId or eventId, not both. This is staff-only: the seller’s own text is not shown to buyers, who see the rejection code and a count.