Skip to main content
Use delivery reads today to understand reported pacing. Do not use them as a claim that a report is final, complete for billing, or delivered to a separate destination. Reliable Reporting is in controlled staging; its status, notification, delivery-evidence, and receipt features are not public API, MCP, or SDK features.

​
Pick the read that answers your question

The reporting metrics endpoint and V3 compatibility reads are seller-reported delivery. live_campaign_delivery is read from the connected provider for that call and does not use the reporting store. Neither path makes a current timestamp or scheduled source cadence evidence that all delivery has arrived. Keep the requested date range with the result, and treat missing source or package data as incomplete rather than zero.

​
Finality is not inferred today

SNAPSHOT and OFFICIAL are the finality classes Reliable Reporting is preparing. A snapshot can change; an official result is the source’s intended final result for its reporting period. Both can later be superseded by a restatement. The current V2 compatibility data behind V3 get_delivery does not include ordered revision evidence. Its finality result is therefore unavailable and its revision is null; Apostra does not infer SNAPSHOT or OFFICIAL from fresh data, a source response, or a delivery cadence. A source may provide is_final or finalized_at for a package-level delivery response. That alone is not an overall finality decision for a media buy or campaign that spans more than one source. The planned Reliable Reporting rule is that a combined result is final only when every required source leg is final. That cross-source rule is controlled staging only.

​
Status, corrections, and receipts

There is no public get_reporting_status read today. There is also no public reporting revision ledger or receipt that proves a report was delivered, received, checked, or eligible for billing. A correction in the current pipeline can replace the current delivery value without exposing a public restatement history. Use current delivery reads for operational pacing, then retain your own reconciliation records until the public Reliable Reporting contract is available. See Reading reporting for the available reporting endpoints.

​
Reporting notifications are not available yet

The planned Reliable Reporting notifications are:
  • reporting.status_changed for a committed reporting health change.
  • reporting.delivery_ready for a verified managed delivery.
  • reporting.ledger_changed for a receipt or reconciliation change.
They are not public events today. Do not configure a reporting-specific reporting_webhook or build a consumer around these names yet. Existing buyer webhooks remain a separate contract and do not provide Reliable Reporting status or receipt evidence. When the staged notifications are public, they will be compact signals rather than report payloads. A consumer will use get_reporting_status to recover the authoritative state after duplicate, out-of-order, or missed events. There is no runnable public SDK example for that flow until the API and SDK are released.