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

# Multi-platform reporting

> How Apostra reads delivery when one campaign uses more than one seller or platform.

## One campaign, several sources

A campaign can contain media buys from several sellers or platforms. Apostra
keeps each media buy and package in the buyer's reporting hierarchy, then
combines compatible rows for the view you requested. This lets you read one
campaign while preserving the source that supplied each delivery record.

The same rule applies when a single storefront media buy fans out to several
inventory sources. A source's delivery remains a separate leg until Apostra
can prove the values are comparable.

## How duplicate delivery is avoided

The reporting pipeline keeps the latest report for each reporting day, media
buy, and source. The source is part of that key. A retry from one source
replaces that source's earlier report for the same day; it does not replace a
different source's delivery for the same media buy and day.

Send cumulative-to-date delivery again when you retry a webhook or poll
response. Do not manufacture an idempotency header: source delivery is
deduplicated from the report data and source identity, not from a
`X-Scope3-Webhook-Id` header.

## Currency is never guessed

Apostra can add monetary values only when they share one denomination or have
an applicable conversion for the reporting view. If a storefront delivery read
contains spend in more than one currency, it withholds the buy-level currency
and monetary totals and returns `MIXED_CURRENCY_DELIVERY`. Read the source legs
separately instead of adding EUR and USD together.

The buyer reporting endpoint can use booked or historical foreign-exchange
rates for an advertiser's primary currency. Its cross-currency consolidated
view is an estimate for display, not a billing or settlement amount. See
[Currency in reporting](/v2/guides/reporting-overview#currency).

## Coverage and partial reporting

**Coverage** says which part of the requested scope a report represents. A
report is partial when a seller, platform, package, or reporting day in the
requested scope is missing or cannot be included. Partial does not mean zero
delivery.

In current delivery reads, a source that cannot be read is returned as an
error rather than silently treated as zero. A package that cannot be attributed
to exactly one source is omitted from `by_package` and named in the response
errors. Those safeguards keep an incomplete source response from appearing as
a complete campaign total.

Reliable Reporting will make coverage an explicit part of each obligation and
revision. That capability is still in controlled staging and is not available
on the public API today. See [Reliable Reporting](/v2/guides/reliable-reporting).

## Practical checks

When you reconcile a multi-platform campaign:

1. Read a bounded date range and retain the response currency and warnings.
2. Treat a missing source, withheld spend, or omitted package as incomplete
   reporting, not as zero.
3. Normalize currencies before comparing values, and keep the response's
   warnings and errors alongside the numbers.
4. Use the buyer reporting hierarchy for campaign rollups and the storefront
   delivery read when you need to see a routed media buy's source-level errors.

See [Reporting overview](/v2/guides/reporting-overview) for the buyer hierarchy
and [Signing the webhooks you send us](/v2/storefront/inventory-sources/webhook-signing)
for seller callback authentication.


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