|

Affiliate and ad networks

Affiliate and ad networks sit between AI agents, content owners (publishers and brands), and merchants. This guide covers how a network participates in OpenAttribution: helping the content owners it works with see AI agent retrieval activity, capturing clickthroughs from AI responses to merchants, and reading aggregated telemetry on behalf of the owners that delegate access.

If your network also serves content to agents (a hosted index, a syndication feed, a proxy), the marketplaces and networks guide covers reporting content_retrieved events with source_role: "index" directly. This page is about the common case where the network does not host the content but wants visibility into how AI agents use it and credit for the conversions it drives.

What works today vs what needs agent adoption
Retrieval events flow today, with no cooperation from the AI agent - a content owner's CDN or origin detects the bot request and reports it. The rest of the chain - which content was loaded into the model's context, what was cited, what the user saw, what they clicked - needs the agent to report it. Start by seeing retrieval; the downstream stages fill in as agent platforms adopt the telemetry standard.

What a network gets out of it

  • A retrieval feed across your content-owner base. Which AI agents are fetching your publishers' articles and your brands' product pages, how often, which URLs, and whether the fetch was a training crawl or a query-time retrieval. This exists nowhere in a standard affiliate dashboard today.
  • Product data is content. A brand uploading feeds to a shopping surface has the same exposure as a publisher whose reviews get paraphrased. Networks that can offer brands the same retrieval view they offer publishers have something to show on both sides.
  • The full influence chain on a click, not just a referring URL. When an AI agent generates an outbound link, the link carries a ctx token. You capture it the same way you capture any affiliate click ID - but instead of one referrer, the token resolves to the set of content that was retrieved and cited in the response that produced the click.

Where retrieval events come from

A network does not have to instrument anything itself to get a retrieval feed. The events are generated by the content owners' own infrastructure. The network's job is to drive adoption across its base:

  1. Publishers and brands publish a manifest. A small static JSON file at /.well-known/openattribution.json declares the domain's identity and where retrieval events should be sent. See the .well-known file. For a network rollout, hand owners the file contents or fold it into whatever tag-management or onboarding step they already run with you.
  2. Their edge or origin reports the fetch. A CDN edge worker (or origin handler) detects AI bot traffic using the platform's native classification and posts a content_retrieved event with source_role: "edge" or "origin". No code changes on the page, no tag updates. See the Cloudflare integration (more CDN and CMS integrations are in progress - see the integrations status page).
  3. The network reads the aggregated data. Once an owner delegates read access to your network (next section), you query their telemetry through the API and build whatever reporting, dashboards, or attribution models sit on top.

The same retrieval can be observed by more than one party - the content owner's edge, and the agent itself if it participates in the protocol. When the agent sends an Content-Telemetry-ID header on its HTTP fetch, both events carry the same UUID and OpenAttribution groups them as one corroborated retrieval. A corroborated retrieval is a stronger signal than either side alone.


Register your network as a platform

Networks register as the platform org type. Setup - sign-up, approval, finding your organisation ID, minting an API key (scope it to telemetry:write for reporting, telemetry:read to also query delegated telemetry, or both) - is the same for every platform. The platform setup guide walks through it; this page is the network-specific detail you come back for.

Capturing clickthroughs and conversions

When an AI agent generates an outbound link, it creates a click token and appends it to the URL as a ctx query parameter. The user (or their agent) clicks the link and lands on a merchant page in your network.

incoming click
https://retailer.com/headphones/sony-wh1000xm5?ctx=ctx_abc123def456

Capture the ctx value the same way you capture any affiliate click ID, and report a content_engaged event. You do not need the agent's session ID - the server resolves ctx_token to the session.

POST /events
curl -X POST https://telemetry.openattribution.org/events \
  -H "X-API-Key: oat_pk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "events": [
      {
        "type": "content_engaged",
        "timestamp": "2026-05-11T10:01:00Z",
        "source_role": "index",
        "content_url": "https://retailer.com/headphones/sony-wh1000xm5",
        "ctx_token": "ctx_abc123def456",
        "data": {
          "engagement_type": "link_click"
        }
      }
    ]
  }'

If the click converts, report a checkout_completed event tied to the same ctx_token. (checkout_completed is defined in the ACP commerce extension, not the core schema.) This closes the loop from agent citation to merchant conversion.

json
{
  "type": "checkout_completed",
  "timestamp": "2026-05-11T10:14:30Z",
  "source_role": "index",
  "content_url": "https://retailer.com/headphones/sony-wh1000xm5",
  "ctx_token": "ctx_abc123def456",
  "data": {
    "value_amount": 34900,
    "currency": "USD"
  }
}

value_amount is in minor currency units (34900 = $349.00).

Looking up the citation chain behind a click

To attribute a click in your own systems you may want the content that was retrieved and cited in the response that produced it. Call GET /ctx/{token} with your platform key:

GET /ctx/{token}
curl https://api.openattribution.org/ctx/ctx_abc123def456 \
  -H "X-API-Key: oat_pk_..."

The response carries the session's content_urls_retrieved and content_urls_cited, the citing agent, and timing. Your network resolves those URLs to content owners and runs its commission logic - the same process as traditional affiliate attribution, with an AI agent in the referral position instead of a webpage.

Click-token lookup is two-sided opt-in
GET /ctx/{token} returns 404 unless both the agent that issued the token has enabled share_sessions_via_click_tokens on its org and the cited content owner has enabled visible_in_click_token_lookups on theirs. Both default to false. Reporting your content_engaged and checkout_completed events is unconditional - they record against the session regardless; only the lookup is gated.

Reading aggregated telemetry

A content owner sees telemetry for their own verified domains by default. For a network to read it on the owner's behalf, the owner delegates telemetry:read to your network's org - they paste your org ID into their /partners dashboard. Once delegated, query their telemetry with your read key and the delegated_from parameter:

GET /content-owners/summary
curl "https://api.openattribution.org/content-owners/summary?delegated_from=<owner-org-id>&since=2026-04-01" \
  -H "X-API-Key: oat_pk_..."

Paginated event-level and URL-level views are at /content-owners/events and /content-owners/urls with the same delegated_from and since parameters. Each delegation is one owner at a time - there is no cross-owner aggregation without each owner's grant. See the Measurement partners guide for the full delegated-read flow and the API reference for response shapes.

To check whether a content URL maps to a registered content owner before you try to credit it, call the public resolve endpoint:

GET /resolve
curl "https://api.openattribution.org/resolve?domain=wirecutter.com"

{
  "domain": "wirecutter.com",
  "handled": true,
  "organization": { "id": "...", "name": "Wirecutter" }
}

The full picture, once agents are instrumented

When both sides are reporting, a single session looks like this:

session
Session: 550e8400-...   Agent: shopping-assistant

10:00:00  content_retrieved   wirecutter.com/reviews/best-headphones      (edge)
10:00:00  content_retrieved   techradar.com/best/wireless-headphones      (edge)
10:00:00  content_retrieved   rtings.com/headphones/reviews/sony-wh...    (edge)
10:00:02  content_grounded    wirecutter.com/reviews/best-headphones      (agent)
10:00:02  content_grounded    techradar.com/best/wireless-headphones      (agent)
10:00:05  content_cited       wirecutter.com/reviews/best-headphones      (agent)
10:00:05  content_cited       techradar.com/best/wireless-headphones      (agent)
10:00:05  content_displayed   wirecutter.com/reviews/best-headphones      (agent)
10:02:30  checkout_completed  retailer.com/headphones/sony-wh1000xm5      (network, via ctx_token)

Outcome: purchase, $349.00 USD

Three content owners' URLs were retrieved. Two were grounded and cited in the response. One purchase resulted. The network resolves the URLs to content owners and runs its commission logic. Today you reliably see the retrieval rows; grounding, citation, display, and engagement fill in as agent platforms adopt the standard.


Conformance and privacy

The retrieval events flowing through your content-owner base are emitted at the retrieval conformance level - standalone events with no session context, correlated to agent-reported sessions via content_telemetry_id. The content_engaged and checkout_completed events you report from a landing page carry a ctx_token in place of a session_id.

The telemetry privacy levels (full, summary, intent, minimal) govern how much conversation detail an agent shares on session data - query text, topics, intent. They do not apply to the retrieval and engagement events a network reports, which carry no conversation content. See specification sections 5.5 and 5.7.


Endpoint quick reference

OperationEndpointKey
Report events (retrieval, engagement, checkout)POST telemetry.openattribution.org/eventsoat_pk_ (telemetry:write)
Look up the citation chain for a click tokenGET api.openattribution.org/ctx/{token}oat_pk_
Aggregated telemetry for a delegating ownerGET api.openattribution.org/content-owners/{summary|events|urls}?delegated_from=…oat_pk_ (telemetry:read)
Check whether a domain is a registered ownerGET api.openattribution.org/resolve?domain=…none (public)
Org, membership, API keys, delegationsapi.openattribution.org/api/v1/identity/*session or oat_ key
Two hosts
High-volume event ingest is on telemetry.openattribution.org - /events and /sessions/*. Reads, lookups, and the control plane are on api.openattribution.org - /content-owners/*, /ctx/{token}, /resolve, /click-tokens, and identity under /api/v1/identity/*. If a content owner self-hosts its telemetry endpoint instead of using OpenAttribution's, send their events to the URL in their manifest.

Next steps