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

# Deliver reporting to Apostra

> Send seller delivery reporting to Apostra and understand what the current callback response confirms.

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:

| Transport | Use it when | What happens |
| - | - | - |
| Webhook | Your agent can send updates as delivery changes. | Post an AdCP `get_media_buy_delivery`-shaped response to the callback URL from the original `create_media_buy` request. |
| Polling | Your agent cannot send outbound callbacks. | Apostra calls your `get_media_buy_delivery` operation on its configured `DAILY` or `MONTHLY` schedule. |
| Bucket | You produce scheduled batch files. | Apostra ingests JSON, JSONL, CSV, or Parquet files when they land in the configured S3, GCS, or Azure Blob path. |

All three transports feed the same day-grain reporting pipeline. See
[Reporting overview](/v2/guides/reporting-overview#how-delivery-data-flows) for
transport setup and [Connect your sales agent](/v2/storefront/inventory-sources/connect-your-agent)
for source connection.

## Send a complete delivery response

Use the AdCP
[`get_media_buy_delivery`](https://docs.adcontextprotocol.org/docs/media-buy/task-reference/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.

<Note>
  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.
</Note>

## 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](/v2/storefront/inventory-sources/webhook-signing).

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


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