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

# Consume reporting

> Use current delivery reads for pacing, and understand the finality and notification boundaries.

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

| Your question | Use today | What it does not answer |
| - | - | - |
| How is seller-reported campaign or media-buy pacing? | V3 `get_delivery` or the buyer reporting metrics endpoint for a bounded period. | Whether every expected source has reported, whether the result is final, or whether it is billing-eligible. |
| What is a connected provider reporting right now? | V3 `get_delivery` with `report: "live_campaign_delivery"` for one exact campaign and a bounded range. | Reporting-store finality, revision history, or billing eligibility. |
| What happened in the buyer workflow? | [Audit logs](/v2/guides/audit-logs). | Delivery performance or reporting finality. |

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


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