> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apostra.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Reliable Reporting

> How Apostra is making reporting status, delivery evidence, and billing reconciliation explicit.

## 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.

<Warning>
  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](/v2/guides/reporting-overview) and `get_delivery` for current
  delivery reads.
</Warning>

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.

| Level | What it establishes | Availability |
| - | - | - |
| Core | A scheduled reporting obligation, immutable report revisions, and an authoritative status read. | Controlled staging rollout; not public yet. |
| Managed delivery | A verified copy of a revision at a file, dataset-share, or warehouse destination. | Not public yet. |
| Reconciled billing | An authenticated consumer receipt for a verified delivery. | Not public yet. |

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:

| Status | Meaning |
| - | - |
| `waiting` | No report is due yet. |
| `healthy` | Every report currently due has been produced and has met the required delivery or reconciliation step. |
| `delayed` | A report is late, but automatic recovery is still running. |
| `action_required` | Automatic recovery has finished or a named party needs to act. |
| `complete` | The requested scope is closed and every required final report is satisfied. |

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](/v2/buyer/reporting/overview) and
[Reporting overview](/v2/guides/reporting-overview).

For several sources or platforms under one campaign, see
[Multi-platform reporting](/v2/guides/multi-platform-reporting).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.