Skip to content
Docs

Reporting API

Use an application-owned Live Key to read batched offer performance. New integrations should use Reporting v2: its earnings projection is always USD and comes from the USD value frozen when each Settlement was created.

Reporting v2 is the default

POST /v2/developer/reports/offers/batch is the current integration path. Reporting v1 remains available for existing per-currency consumers; it has not been changed in place or removed.

Request

Set your Live Key in the local shell. AON Docs never asks you to paste the key into a browser form and does not execute this request for you.

Reporting v2 request
curl
export AON_API_KEY="<application-live-key>"

curl --request POST \
  "https://api.aon.pro/v2/developer/reports/offers/batch" \
  --header "Authorization: Bearer $AON_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "items": [
      {
        "placement_id": "plc_7c2e0dR9kL4mN8pQ",
        "offer_id": "7d45b8ac-27bb-4d8f-9d32-68a9ac01a012"
      },
      {
        "offer_link": "https://aon.link/static/st_8pK4vQ7mN2xR5cT9wY3zD6hJ1sL0bF4"
      }
    ],
    "from": "2026-08-01T00:00:00Z",
    "to": "2026-08-10T00:00:00Z"
  }'

from is inclusive and to is exclusive. Both timestamps must be UTC Z whole-hour boundaries. A batch accepts direct placement_id + offer_id pairs and AON /static/{code} links. A merchant URL is not a report identity.

v2 earnings states

Each successful item reports its own completeness independently from siblings and from the batch coverage window.

Stateestimated_earningsMeaning
completeOne USD entry, including USD 0.00 for a known zeroEvery included Settlement has a frozen USD snapshot
unavailable + missing_usd_snapshotnullAt least one included Settlement lacks its frozen USD snapshot; AON does not return a partial USD subtotal
unavailable + coverage reasonnullThe item has no reliable included data; clicks and conversions are also null rather than invented as zero
{
  "code": "SUCCESS",
  "message": "",
  "data": {
    "results": [
      {
        "input_index": 0,
        "offer_link": null,
        "status": "success",
        "data": {
          "placement_id": "plc_7c2e0dR9kL4mN8pQ",
          "offer_id": "7d45b8ac-27bb-4d8f-9d32-68a9ac01a012",
          "clicks": 201,
          "conversions": 31,
          "earnings_state": "complete",
          "earnings_unavailable_reason": null,
          "estimated_earnings": [{ "amount": "131.15", "currency": "USD" }]
        }
      }
    ],
    "succeeded_count": 1,
    "failed_count": 0,
    "coverage": {
      "data_state": "partial",
      "unavailable_reason": null,
      "requested_window": {
        "from": "2026-08-01T00:00:00Z",
        "to": "2026-08-10T00:00:00Z"
      },
      "included_window": {
        "from": "2026-08-02T00:00:00Z",
        "to": "2026-08-10T00:00:00Z"
      },
      "data_available_until": "2026-08-10T00:00:00Z",
      "reliable_since": "2026-08-02T00:00:00Z",
      "data_may_restate": true
    }
  },
  "extra": { "timezone": "UTC" }
}

The service never performs request-time FX conversion. Coverage describes the reliable time window; earnings_state describes USD completeness inside that window. One invalid, unauthorized, duplicate, or incomplete item does not erase valid siblings.

Limits and errors

  • Authentication is scoped to an application-owned Live Key. The shared Public Test Pair cannot call Reporting.
  • A request accepts at most 10,000 items and 30 days, with a 2 MiB request and 16 MiB response limit.
  • Item errors preserve input order and do not reveal whether an inaccessible pair exists outside the caller's application.
  • Request-level authentication, validation, size, rate-limit, or dependency errors use the standard {code,message,data,extra} envelope.

Migrating from v1

POST /v1/developer/reports/offers/batch remains the compatibility endpoint. It groups earnings by original Settlement currency and does not expose earnings_state. To migrate:

  1. Change only the endpoint from /v1/ to /v2/; request fields and limits stay the same.
  2. Treat estimated_earnings as either one USD entry or null.
  3. Branch on earnings_state and earnings_unavailable_reason; do not convert null to zero.
  4. Keep coverage handling separate from earnings completeness.

Do not sum v1 currency buckets as if they were USD. Keep v1 in place until your consumer has adopted the v2 states and verified its own output.