Skip to content
AON - Agent Offer Network
 

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

Response

AON reads exactly the requested [from, to) window from its database, including the current hour. There is no history floor and no freshness cutoff, so every successful item has numeric clicks and conversions and exactly one USD estimated_earnings entry ("0.00" when there are none). Reversed and frozen Settlements are not counted.

{
  "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,
          "estimated_earnings": [{ "currency": "USD", "amount": "131.15" }]
        }
      }
    ],
    "succeeded_count": 1,
    "failed_count": 0
  },
  "extra": { "timezone": "UTC" }
}

The service never performs request-time FX conversion. Values for an older window can still change as late conversions arrive or Settlements are reversed, so re-query any window you need to keep current. One invalid, unauthorized, or duplicate 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. A system error such as INTERNAL_ERROR fails the whole request; retry it later.

Migrating from v1

POST /v1/developer/reports/offers/batch remains the compatibility endpoint. It groups earnings by original Settlement currency and still returns its legacy coverage object, which now always reports the requested window as complete. To migrate:

  1. Change only the endpoint from /v1/ to /v2/; request fields and limits stay the same.
  2. Read estimated_earnings as exactly one USD entry.
  3. Stop reading coverage; v2 does not return it.

Do not sum v1 currency buckets as if they were USD.