Skip to main content

​
What Reliable Reporting changes

Reporting is most useful when you can answer three separate questions: what has been reported, whether the report is complete for the scope you asked for, and whether a later correction can change it. Reliable Reporting is the AdCP 3.2 model for answering those questions with an explicit record rather than a guess based on how recently a source responded.
Reliable Reporting is in a controlled staging rollout. It is not yet available through Apostra’s public API, MCP server, or SDK. In particular, get_reporting_status, reporting notifications, managed delivery, and reporting receipts are not public features today. Use the existing Reporting overview and get_delivery for current delivery reads.
The terms on this page describe the contract being prepared for that rollout. They do not change the behaviour of existing 3.0 and 3.1 reporting ingestion: seller webhooks, polling, and bucket delivery continue to feed the current day-grain reporting pipeline.

​
Three levels of assurance

Reliable Reporting has three levels. Each level builds on the one before it. Core does not require a destination or receipt. Managed delivery adds evidence that a consumer can read the delivered data. Reconciled billing adds the consumer’s acknowledgement, so billing can distinguish data that was produced from data that was received and checked.

​
The records behind a report

An obligation is created before the report is due. It fixes the reporting period, schedule, required finality, selected media buys, and coverage rule for that period. A later campaign or configuration change affects a future obligation, not the one already recorded. When data is ready, it becomes an immutable revision. A revision identifies the report definition, period, coverage, finality, row count, and control totals (the totals used to check the report). A zero-row revision is still a report: it says that the source checked the period and found no rows. A correction is a new revision, called a restatement. It links to the revision it replaces; it never overwrites the earlier revision. That leaves a reader able to see both what was first published and what superseded it.

​
Status is an operational answer

The planned get_reporting_status read will provide one of five health states for the requested scope: Coverage and finality remain separate. A fresh report can be partial; a complete report can still be a snapshot; and an official report can later be restated. The status read is designed to make those limits visible instead of treating a recent timestamp as proof.

​
Notifications and recovery

The planned notification types are compact doorbells, not report delivery:
  • reporting.status_changed will signal a committed health change.
  • reporting.delivery_ready will signal a verified managed delivery.
  • reporting.ledger_changed will signal a receipt or other reconciliation change.
Notifications can be repeated, arrive out of order, or be missed. Consumers will use get_reporting_status to recover the authoritative state. Apostra will advertise a notification only when that notification and its signed delivery path are available.

​
What to use today

For delivery and pacing today, call get_delivery or the day-grain buyer reporting endpoint. Treat them as seller-reported delivery. They do not expose Reliable Reporting revisions, authoritative status, managed-delivery evidence, or billing receipts. See Reading reporting and Reporting overview. For several sources or platforms under one campaign, see Multi-platform reporting.