Skip to main content
This guide is for a seller whose inventory source reports delivery to Apostra. It covers the reporting pipeline available today. Reliable Reporting status, managed delivery, and receipts are in controlled staging and are not public API, MCP, or SDK features.

​
Choose a transport

At source registration, choose the transport that fits your delivery system: All three transports feed the same day-grain reporting pipeline. See Reporting overview for transport setup and Connect your sales agent for source connection.

​
Send a complete delivery response

Use the AdCP get_media_buy_delivery shape. A usable report includes reporting_period and media_buy_deliveries. Report the media buy that Apostra asked about, with its actual delivery totals and the currency those monetary values use. Include by_package lines when you can attribute delivery to the booked packages. A package line needs its own usable currency, pricing model, and rate for Apostra to return it as a complete package-level result. If one source reports a total for several packages, or a package cannot be described without guessing, Apostra omits that package line and reports the reason rather than inventing an allocation. Report only observed delivery. A missing source, package, or reporting day is not zero delivery. For a reporting range with more than one day, provide the AdCP daily breakdown when your source has the day-level evidence.

​
Correct a report

The current pipeline retains the latest delivery for each reporting day, media buy, and source. To correct a delivery value, send the cumulative-to-date response again with the corrected value. A retry from your source replaces that source’s earlier report for the same day; it does not replace another source’s report for the same media buy and day. Do not create a X-Scope3-Webhook-Id header for retries. Delivery is deduplicated from the report data and source identity, not from that header. is_final and finalized_at can describe a package-level result in an AdCP delivery response. Today, Apostra does not expose an overall finality decision for a media buy that spans several sources, and a correction does not create a public reporting revision or restatement record.
Reliable Reporting is preparing explicit revisions and cross-source finality. The planned rule is that a combined result is final only when every required source leg is final. That behavior is controlled staging only and is not available to public consumers yet.

​
Verify webhook delivery

For webhook delivery, sign the exact body sent to the callback URL with the per-callback credentials from push_notification_config in the request you are answering. Send X-ADCP-Timestamp as Unix seconds and X-ADCP-Signature as sha256= plus the lowercase HMAC-SHA256 digest. Apostra allows 300 seconds of clock skew. Follow the full signing contract and reference implementations in Signing the webhooks you send us. A 200 response confirms that Apostra accepted the callback and dispatched the report for asynchronous ingestion. It is not a reporting receipt and does not prove that the report was later processed. A 401 means to check the callback-specific signing credentials, timestamp, and exact body bytes. An oversized list of delivery legs is rejected with 413; split the report before trying again. There is no public reporting receipt, no-spend receipt, or get_reporting_status read to verify later processing today. Do not treat a recent callback response, a source cadence, or a package-level finality field as proof of billing eligibility. For current buyer-visible delivery reads, see Reading reporting.