Agent Offer Network (AON) FAQ

Agent Offer Network (AON) is the offer network for AI-native commerce. It can connect an AI product with eligible structured merchant offers and preserve attribution from user intent to a later reported outcome.

The AI product controls whether and how to present an offer. The merchant remains responsible for current price, checkout, payment, order acceptance, and fulfillment. A reported outcome must satisfy attribution, validation, and the applicable commercial terms before commission is payable.

No. Agent Offer Network (AON), at aon.pro, is not affiliated with Aon plc, AION, AEON, or other organizations that use similar names.

The name was chosen to describe its role in AI-native commerce directly: Agent refers to AI agents and apps, Offer to structured Merchant Offers, and Network to the Publishers, Merchants, Advertisers, and Partners connected through offer discovery and attribution.

Agent Offer Network (AON) is not a general marketplace for AI services or a payment rail. It does not sell arbitrary APIs, execute merchant checkout, hold payment credentials, authorize transactions, or fulfill orders.

AON connects AI products to structured merchant offers and preserves evidence for attribution after a tracked interaction. Merchants and their commerce systems remain responsible for current terms, checkout, payment, order acceptance, and fulfillment.

AON is closer to AI commerce infrastructure than a classic ad network.

It can support affiliate-like outcome monetization, but it is designed around AI product workflows: intent matching, structured offer data, native rendering, and attribution. That makes it different from inventory-led ad networks and from manually placed affiliate links.

AON is built for AI product workflows where offers need to match live user intent and appear inside the product's own experience.

Traditional affiliate networks can work well for websites, content pages, tracked links, feeds, and program relationships. AON focuses on a different use case: retrieving structured offers for AI surfaces, letting the publisher render them natively, and preserving attribution through AON tracking and postback flows.

See details in AON tracking docs.

Use AON when the offer should be selected from the user's current AI task rather than inserted as a fixed link or visual ad slot.

Affiliate links can work for static content, and display ads can work for inventory-based placements. AON is a better fit when recommendations need intent matching, structured offer data, native presentation, and outcome attribution.

AI products need a different monetization layer because the user experience is dynamic, conversational, and often has no fixed ad slot.

AON is designed to match offers to the user's current task, return those offers as structured data, and let the AI product render them in a way that fits the workflow instead of forcing a generic ad placement.

AON is mainly for AI product builders, publishers, app developers, agent teams, and advertisers working around high-intent user tasks.

It is most relevant when an AI product already helps users compare, choose, book, buy, subscribe, or take another commercial next step. These are common agentic commerce workflows.

AON is probably not the right fit when the product has no clear commercial intent or when an offer would interrupt the user's task.

It works best when a recommendation can genuinely help the user move forward. If the goal is only to fill empty space with ads, AON is the wrong framing.

You can monetize an AI product with AON when a user continues through a documented Offer action and the Merchant or Partner reports a qualifying outcome.

The product requests relevant Offers, decides whether to render one natively, preserves the documented attribution path, and checks the reported outcome against the Offer's Goal and applicable commercial terms. A click or referral alone is not a guaranteed payout.

Once your AI product is configured to present a relevant AON offer, it preserves the documented attributed action when the user continues to the seller. The seller or supply partner later reports the qualifying sale, signup, booking, or other Goal through the configured path.

AON evaluates the attribution evidence, Goal match, validation, and commercial terms before the outcome can become payable commission. A click or referral alone is not a guaranteed payout.

It depends on the qualifying event that the merchant or supply partner defines for the offer. A click or referral does not have one universal commission treatment.

A referral can earn commission when it is explicitly defined as the payable event in the applicable commercial terms and it passes attribution and validation. If the offer instead requires an order, purchase, booking, signup, or another downstream outcome, the click or referral preserves attribution but does not qualify on its own. The defined outcome must still be reported and pass the applicable validation and commercial-term checks.

Yes, AON is designed for AI-native products such as chatbots, agents, assistants, and workflow tools.

AON fits best when the product can understand what the user is trying to do, request relevant offers, and present them as a natural part of the answer or workflow.

No. AON does not require a minimum traffic level to join.

You can integrate AON while your audience is still growing. Starting early gives your team time to learn which user requests indicate purchase, booking, or signup intent, test where an offer genuinely helps, and refine the experience before traffic scales.

Offer availability and commission still depend on eligible supply and the qualifying outcomes defined for each offer.

Before an offer can be returned in an AON integration, it must meet the structured-data and serving requirements for its supply path. AON applies the eligibility and targeting rules supported by the active integration; an offer that does not meet those requirements is not eligible to be returned.

This does not make AON a general safety or compliance certification. Merchants remain responsible for product information, current terms, checkout, and fulfillment.

See details in AON Partner offer fetch docs and AON Offer Query docs.

Available merchants and offers vary by request. We do not currently provide a public directory or one network-wide count because eligibility can change by market, category, partner status, environment, and the request itself.

Send a live Offer Query or use MCP search without an account or API key to see eligible offers and their merchant information. Add your Placement ID to attribute traffic and earn. The Public Test Sandbox returns fixed, non-billable data and does not show live production supply.

See details in Offer Query docs and Public Test Sandbox.

Offers can appear wherever they naturally support the user's task.

Common surfaces include inline recommendations, merchant cards, actionable banners, comparison modules, booking widgets, product grids, and custom UI that matches the publisher's product design.

No, AON does not require one fixed ad unit.

AON returns structured offer data so publishers can choose the presentation surface. The integration still needs to preserve required tracking, disclosure, and merchant rules.

See details in Structured offer schema and Offer Query docs.

After a user follows an AON Offer action, they continue to the Merchant or Partner destination. The agentic checkout or other transaction flow runs in that destination, which handles checkout, payment, order acceptance, and fulfillment.

AON preserves the tracking context from the AI product. The Merchant or Partner can later report a qualifying outcome; AON then evaluates attribution, Goal matching, validation, and the applicable commercial terms before commission is payable.

The product should continue gracefully when there is no matching offer.

A good integration can show nothing, keep the original answer flow, use a neutral fallback, or ask for more context. It should not force a low-relevance recommendation just because an offer slot exists.

Use AON only when the offer is relevant to the user's current intent and useful as a next step.

Publishers should avoid over-inserting offers, disclose commercial recommendations where required, and keep answer quality ahead of monetization density.

Show a clear label close to the offer, link, card, or other recommendation surface so users can understand the commercial relationship before they act. The AON SDK includes a disclosure by default when it formats a recommendation, using Sponsored as the default text; publishers can customize that label for their surface.

Disclosure requirements vary by market and product context. Publishers remain responsible for making sure the wording and placement meet their own legal and policy obligations.

AON can return eligible offers with relevance signals or ordering under the selected integration contract. Your app retains the product decision about whether to show a returned offer, where it appears, and how it is presented.

A returned offer is not a mandatory placement or a guarantee that it is the universally best choice for every user.

No. AON does not require your product to show a returned offer or replace a better answer.

Your product should show an AON-powered offer only when it is relevant to the user's stated intent, appropriate for the surface, and clearly disclosed where required. You retain control over whether an offer appears and how it fits the answer.

No. An AON Offer Query returns discovery-time information from the active supply path; it does not guarantee that a price, inventory status, eligibility condition, or promotion will remain unchanged.

Query again when freshness matters, and do not describe returned values as guaranteed or real-time unless the active supply path expressly supports that claim. The merchant or checkout system remains the authority for the current price, availability, transaction eligibility, and binding terms.

See details in Offer Query docs.

A typical AON flow starts with an AI product sending user intent and context, then using agentic offer discovery to receive structured offers, render one or more offers, and preserve attribution for clicks or downstream outcomes.

The exact implementation can use SDKs, direct API calls, or platform adapter paths depending on the product architecture.

See details in Offer Query docs and Tracking docs.

A Developer integration uses AON inside an AI product to query, present, and attribute offers. A Partner integration supplies eligible offer inventory to AON and reports downstream outcomes.

The two paths use different portals, identity and access rules, contracts, and operational responsibilities. Developer search can run anonymously; attribution needs a Placement ID.

See details in Developer Quick Start and Partner integration.

Choose Content Assistant for an AON-hosted assistant on your website, or Offer Wall for a browsable list of offers through a hosted page or your own UI.

Choose REST or the TypeScript SDK when your product should control offer search and presentation. Use MCP when a compatible AI host should discover and call AON's offer-search tools. The guides below explain setup for each path.

See details in Content Assistant guide, Offer Wall guide, TypeScript SDK and MCP connection setup.

A Placement ID identifies an AON offer surface and connects its traffic to your Application. It is public, so you can include it in a website or app.

Send it with Offer Query or MCP search to attribute traffic and qualifying earnings. Searches without it are anonymous and cannot earn or be attributed to your Application retroactively. An API key is a separate credential for account operations such as Reporting and Offer lookup; keep it on your server.

See details in Get your Placement ID, Placement ID definition and Reporting API.

You can start a basic prototype with the Quick Start and mock mode.

The time needed for production depends on your integration path, offer-surface design, disclosure, analytics, account enablement, and testing.

See details in Quick Start docs.

No. You can use an AON-hosted Offer Wall without building a custom interface, or add Content Assistant to a website with the aon.js script.

A custom API integration is useful when you want to build and control your own offer experience. Both hosted options use a Placement ID to connect traffic to your Application.

See details in Content Assistant guide, Offer Wall guide and SDK docs.

Yes. Create a Content Assistant placement and add the aon.js script with its Placement ID. The assistant uses your public page and visitors' questions to help them discover relevant offers.

The web script supports a floating button and an end-of-content entry point. The latter needs a static slot on a public HTTPS page. Check the guide for supported styles, page-access requirements, and single-page-app limits; the native iOS and Android package is not published yet.

See details in Content Assistant guide, aon.js Web Plugin reference and Content Assistant definition.

Yes. Open your placement's AON-hosted Offer Wall in a browser or an in-app WebView. AON provides the list interface and handles paused and empty states.

You can later build a custom list through the Offer Query API using the same placement and user attribution. The guide covers both options.

See details in Offer Wall guide and Offer Wall definition.

No. Live Offer Query and MCP search work without an account or API key. Without a Placement ID, searches run anonymously and earn no attribution or payouts.

For local prototypes, SDK mock mode uses in-memory sample offers. The Public Test Sandbox returns fixed, non-billable data. Neither test path proves live offer availability or creates attributable traffic.

See details in Quick Start docs, Public Test Sandbox and Get your Placement ID.

AON provides a TypeScript SDK, and teams can also integrate directly through REST.

Choose the path that best fits your stack; the SDK documentation has the installation and usage details.

See details in TypeScript SDK reference.

Yes. AON works at the application layer and can be integrated into products built with different model providers.

Use REST or the TypeScript SDK for application-controlled integration, or MCP where the host supports it. Available setup options depend on the host and product environment. Use the current integration guides when choosing a setup.

See details in Current integration guides.

Yes. Compatible MCP hosts can search AON offers without an account or API key. Search without a Placement ID is anonymous and earns no attribution or payouts; a serviceable Placement ID attributes traffic. AON also provides SDK, REST, and platform-specific paths.

MCP clients should use the active server's tools/list response as the authority for currently available tools and input schemas.

See details in Integration guides and Claude integration.

AgentOffer Protocol defines the portable Query, Offer, control, and MCP tool behavior that AON-compatible systems share. MCP is the interface an AI client uses to discover and call an AON deployment's tools.

The protocol defines how compatible tools and data behave. Each deployment separately determines endpoint availability, account access, and the live tools exposed through tools/list.

See details in AON MCP docs and AgentOffer Protocol.

Anonymous offer search needs no account or API key and earns no attribution or payouts. Add a valid Placement ID for attributable search.

Feedback and watch management need an active Placement ID in the X-AON-Placement-Id header on every call, with no API key. A Placement ID in the request body or query string cannot replace this header for those tools. Reporting and Offer lookup use separate server-side credentials; see their API references.

Yes. The hosted Offer Query API supports pagination.limit and pagination.offset. Use a new request_id for each page and reuse it only when retrying that same page.

Keep the intent and constraints consistent across pages. Inventory and ranking can change, so deduplicate by offer_id and handle empty results. Offer Wall integrations should follow their documented next-offset and has-more response fields.

See details in Offer Query pagination and Offer Wall API.

Yes. Offer Wall click links do not expire solely because time has passed and can be cached and reused. A link remains usable while the application can serve traffic, the placement is active, and the offer remains selected on that placement.

If those conditions no longer hold, the link opens an unavailable page. Refresh the list with the viewer's current location context when they return. Preserve the tracked action instead of replacing it with an untracked merchant URL.

See details in Offer Wall link lifetime.

Save the original offer_instance_id unchanged and use the Offer Instance API from your server to retrieve the card. Treat the ID as an opaque value; its format does not tell you when the offer was served. The original Query must include your Placement ID so your Application can retrieve the card later.

The API returns the original tracked link while it remains usable. OfferInfo instead reads stored details by offer_id and does not return a tracked action. If the card has no action, show an unavailable state. Both APIs need a server-side Live API Key and do not guarantee current merchant price or availability.

See details in Offer Instance API, OfferInfo API and Offer instance definition.

Send the user's current text or image intent and only the fields supported by your active integration. Relevant context can include viewer country, canonical location IDs, or a verified minimum-age threshold under context.user_profile.

Omit unknown optional values. Use actual viewer location signals rather than a destination mentioned in the request, and never infer age or other personal attributes. Send bounded context instead of a full conversation history; the active documentation or tool schema defines the exact fields.

See details in Location targeting and Offer Query docs.

Do not invent missing user details or treat guesses as hard eligibility facts. Your app can ask a focused follow-up question, omit optional context, or continue with a broader request when the active contract supports it.

If the missing detail is required for a safe or valid next step, the product should wait for the user rather than force an offer result.

No. Creating an account, reading the public protocol, or completing a sandbox request does not create attributable production traffic.

SDK mock mode runs locally with sample data. The Public Test Sandbox uses shared, fixed, non-billable test data. Live Query and MCP search can run anonymously without registration, but anonymous traffic earns no attribution or payouts.

For attributable live traffic, create a serviceable Application and send its Placement ID. Reporting and other account-scoped routes require their documented credentials.

See details in Get your Placement ID and AgentOffer Protocol.

AON uses attribution to connect an offer interaction to the AI product and publisher surface that generated it.

AON preserves tracking context through the tracked action, destination, click reporting, conversion event, and partner postback. It then evaluates the reported outcome against that context, so credit does not depend on manual reconciliation alone.

See details in Tracking docs.

The AI product preserves the documented tracked action when the user continues to a merchant or partner destination. The merchant or supply partner later reports the qualified downstream event through its configured server-to-server path, allowing AON to evaluate it against the original offer interaction.

The merchant remains authoritative for checkout and order confirmation. A reported event still needs attribution, Goal matching, validation, and settlement checks before it becomes payable commission.

AON does not require a user's name, email address, ChatGPT identity, or AON account for its normal Offer-attribution path. It uses tracking context such as the Offer interaction and anonymous click identifiers to connect a later reported outcome with the originating AI product.

The AON Privacy Policy explains the additional technical data involved when a user follows an Offer. AON Shopping records the click with the user's IP address and user-agent, forwards standard request headers to the destination, and may provide a derived pseudonymous visitor identifier when the Partner destination requests one. That identifier is not derived from or linked to the user's name, email address, or account. Direct API, SDK, and Partner integrations should send only the fields required by their active integration and follow the applicable data-processing terms.

See details in Privacy Policy and Tracking docs.

AON integrations should send only the intent and context needed to return relevant, eligible offers.

Use only the fields documented for the active integration. Omit optional values when they are unknown, and do not infer personal, location, or eligibility attributes from free text.

AON is designed to collect the minimum information needed to return relevant results and operate the partner network reliably.

See details in Privacy Policy and Offer Query docs.

No. AON does not request, store, or attempt to access conversation history outside the request sent to AON. Publishers should send only the text, image, or context needed for Offer matching and eligibility.

The request itself is subject to the retention rules in the AON Privacy Policy. Search queries and tool-invocation metadata have a default seven-day retention window in the primary database, and a copy is exported to the analytics warehouse where it is not covered by that purge. Operational logs are typically retained for no longer than 30 days. Click records used for attribution reconciliation and settlement history do not currently have a scheduled deletion job, apart from automated cleanup of test-generated records.

See details in Privacy Policy.

AON Offer Goals use CPA or CPS pricing. One Offer can declare multiple explicit Goals, such as a qualified action under CPA and a confirmed sale under CPS, to form a hybrid commercial arrangement; hybrid is not a separate pricing value in the current Offer contract.

Each Offer identifies the qualifying Goal and its applicable commercial terms. Rates, payout timing, fees, and settlement terms depend on the Offer, onboarding, and the applicable commercial terms.

See details in Commission model definition.

Choose the commission model that matches the value the Merchant can verify. CPA can fit a qualified lead, signup, install, or booking; CPS fits a confirmed sale. A hybrid arrangement combines multiple explicit CPA and/or CPS Goals and is not a separate pricing value in the current Offer contract.

The decision should reflect the Merchant's economics, the events it can report reliably, and the validation needed before revenue is payable. CPC is a common advertising model, but it is not a current AON Goal-pricing model.

Attach your own user reference as sub_id to the hosted Offer Wall URL or the returned tracked link, following the guide. AON includes that reference in conversion and earning updates so your system can associate an outcome with the right user.

Your app decides when rewards become spendable and how refunds or rejected earnings affect them. Verify and deduplicate webhook deliveries before changing a balance. Use the latest earning status rather than treating every update as an extra reward.

See details in Offer Wall attribution, Crediting users by sub_id and Sub-ID attribution definition.

No. A confirmed earning acknowledges the conversion; it is not yet available for payout. New conversions use automatic confirmation by default. Sources configured for manual confirmation retain their individual or monthly-statement process.

Use the latest earning status: earning_available means available for payout, and earning_paid_out records AON's completed payout. It does not certify receipt in your bank account. Confirmation updates arrive asynchronously, with no fixed delivery interval.

See details in Earning status events and Commission settlement.

Attach your own user reference as sub_id, then use verified conversion and earning updates to manage that user's reward. Your application decides when to credit the reward.

Deduplicate deliveries and keep the largest sequence for each earning_id. Event amounts describe the current earning, so do not add them together. On rejection, reverse only rewards already credited. A later update with a larger sequence can restore an earning; follow the webhook guide when applying the corresponding reward.

See details in Crediting users by sub_id and Offer Wall rewards.

A reported conversion is an estimated earning, not a final payout. Refunds, merchant validation, and review adjustments can change the amount or prevent it from becoming payable.

Subscribe to earning status webhooks to follow confirmation, availability for payout, payment, and rejection. Use the latest state for each earning rather than adding update amounts together. A paid-out event records AON's payout; it does not certify receipt in your bank account.

See details in Earning status events and Reporting API.

Your earning depends on the Offer's qualifying Goal and pricing terms, the AON platform fee, and validation of the reported outcome. CPA Goals specify a fixed amount; CPS Goals specify a percentage. The listed pricing is before the platform fee, while the conversion webhook reports your expected net earning in USD.

Under the October 15, 2026 update, new positive net earnings are rounded up to the next USD 0.01 after fees and currency conversion. Later earning updates can change the payable amount. See the webhook guide for exact amount formats and treatment of older conversions.

See details in Webhook amounts, Commission update and Offer Wall rewards.

No. A click or reported conversion provides evidence for attribution; it is not automatically a final payout.

The reported event must match the served Offer's Goal and pass the applicable attribution, validation, deduplication, risk, refund or cancellation, reconciliation, and commercial-term checks before it can become payable. Rates, fee splits, payout timing, any thresholds, and settlement schedules depend on the applicable offer, account, and commercial terms. Estimated earnings shown in reporting are not finalized settlement amounts.

See details in Earning status events, Reporting API and Commission settlement.

Enabled Developer accounts can use AON's application-scoped reporting API to retrieve clicks, conversions, and estimated earnings for supported offer references.

Estimated earnings are not finalized settlement amounts. Reporting availability depends on the authenticated application and available coverage.

See details in API reference.

Merchants and Advertisers can advertise through AON by making structured Offers available, defining qualifying outcomes, and agreeing commercial terms so compatible AI products can consider eligible Offers for relevant user requests. The Advertiser owns the Offer program and commercial terms; the Merchant owns the product or service, transaction destination, and fulfillment. One business can perform both roles, or a supply Partner can connect the Offer to AON and report downstream outcomes.

The AI product decides whether an Offer helps the user's current task and controls its presentation. AON does not guarantee placement, recommendation, or conversion.

Not always. The Merchant owns the product or service and destination experience, while the Advertiser owns the Offer program and commercial terms; the same business can perform both roles. An approved supply Partner may expose Offers from one or more Merchants to AON and report downstream outcomes.

The required setup depends on the approved supply path. A Merchant does not generally need to build an MCP server, provide an agentic checkout API, add Schema.org markup, or send its catalogue directly to AON unless the selected integration requires it. Merchants remain responsible for current Offer information, price, availability, checkout, payment, and fulfillment.

See details in Partner integration.

AON needs structured offer data that can be queried, ranked, rendered, tracked, and attributed safely.

At a minimum, a partner should provide clear offer content, merchant identity and destination, supported eligibility conditions, the applicable Goal and commercial terms, and postback responsibility for qualified outcomes. Supply Offer Profiles document category-specific fields for Flight, Hotel Rate, and Game Offers, so partners can map their data to the appropriate profile. AON uses only targeting inputs supported by the active integration. Submitting offer data does not guarantee delivery, presentation, current availability, or conversion.

See details in OfferProvider API, Supply Offer Profiles and Game Offer Profile.

Yes. AON supports outcome-based commercial arrangements in which a merchant defines a qualifying event and pays only after it is attributed and validated. A sale can use CPS terms; a qualified lead, signup, booking, or install can use CPA terms.

The merchant or supply partner must be able to report the defined outcome reliably, and the applicable commercial terms determine final settlement.

Advertisers can define supported offer conditions in their supply setup, but they do not directly control an AI product's presentation decision.

AON and the active deployment apply those conditions using the request inputs they support. The AI product still decides whether a returned offer helps the user's task, and merchant checkout remains responsible for final transaction eligibility.

See details in Category taxonomy and Location targeting.

AON supports recommendation quality by making offers structured, attributable, and tied to user intent rather than generic ad inventory.

Publishers should still control when offers appear, avoid irrelevant placements, disclose commercial recommendations where required, and prefer no offer over a low-quality recommendation.