How do I capture a sale an AI agent made?

Fire your Conversions API event from the order-confirmation step your backend already runs - a checkout webhook, an order API, or the payment provider's success callback - instead of relying on a browser pixel. Do this because a portion of agent purchases complete with no browser session and no JavaScript execution at all, so a pixel never gets the chance to fire. As of September 2026 most agent-initiated purchases still redirect a human into a browser checkout, so confirm which path you actually have before assuming you need the zero-JS server-only build.

Do all AI agent purchases skip the browser entirely?

No, and this is the most common misreading of the agent-commerce story. Since OpenAI's Agentic Commerce Protocol Instant Checkout was rolled back in March 2026, the dominant pattern is an agent discovering or recommending a product and then redirecting a human into a normal browser checkout on the merchant's own site - a referral-attribution problem, not a zero-JS one. True API-only purchases, with no browser step anywhere, still happen, but in narrower channels: B2B procurement agents calling a merchant order API directly, agent-issued corporate-card transactions, and AP2-mandated payments authorized without a browser session.

What happened to ACP Instant Checkout, and does it change what I need to build?

OpenAI and Stripe's Agentic Commerce Protocol shipped an Instant Checkout flow that let a purchase complete inside the chat interface itself, with no merchant-site browser step. That flow was rolled back in March 2026; the model most agent commerce now uses is product discovery followed by a merchant-site redirect where a human completes checkout. It changes the build priority: get redirect-path referral attribution and standard CAPI right first, then build the true zero-JS server event only for the narrower channels that still produce one.

Do I still need pixel-side dedup for an agent-checkout CAPI event?

It depends which path produced the sale. If the agent redirected a human into your normal browser checkout, the pixel fires as usual and standard CAPI-plus-pixel dedup applies, unchanged. If the purchase was a true API-only agent transaction with no browser step at all, there is no pixel event to deduplicate against - the server event is the only signal, and sending a synthetic client-side event to match it would create a false view rather than solve a dedup problem.

Capturing Agent Checkout Via CAPI When The Purchase Is An API Call

Two different problems wearing one name

"Capture the agent sale" gets used for two structurally different problems, and building the wrong one wastes the engineering effort. Separate them first.

Path	What actually happens	The real problem
Discovery + redirect	An agent recommends or searches for a product, then hands the shopper a link; a human completes checkout in a normal browser on your site. The pixel fires. A session exists.	Referral attribution - the session often shows as Direct/none or an untracked referrer, not that no signal exists at all. This is the same undercounting problem covered on ai.webclat.com, applied to your last click before conversion.
True API-only checkout	An agent completes the transaction itself through a merchant order API, a procurement integration, or an AP2-mandated payment, with no browser step anywhere in the flow.	Capture - there is genuinely no client-side event to rely on, ever, for this transaction. This is what the rest of this page is about.

Most published "agents are invisible to analytics" framing describes the measurement blind spot in general (see the landscape figures on ai.webclat.com) without separating these two paths. Since the March 2026 ACP rollback, the redirect pattern is the majority of agent-driven commerce; treat it as a referral-attribution fix, not a CAPI build. Reserve the server-only build below for transactions that were never going to produce a browser session in the first place.

Where to hook the server-side event

For a true API-only agent checkout, the Conversions API call has to originate from the same backend step that already knows the order happened - not from anything running in a browser, because nothing is. In order of how often this maps cleanly onto an existing system:

The order-confirmation webhook. If your commerce platform or payment processor fires a webhook on successful payment (Stripe, a merchant order API, an internal order service), attach the Conversions API call as a handler on that webhook. This is the same event your fulfillment and email-receipt systems already consume - reuse it rather than building a second listener.
The payment provider's success callback. For an AP2-mandated payment, the signed Payment Mandate's settlement confirmation is the equivalent trigger - fire the conversion event when the mandate settles, not when it is merely authorized.
Server-side GTM, if you already run one. Route the order event into the same container handling your other server-side tags (see gtm.webclat.com) rather than hand-building a second HTTP call per ad platform - this is the path we recommend when a container already exists, the same guidance as the general CAPI framework on /capi/.

What you will not have, for a true API-only transaction: a click ID (gclid, fbclid) from a browser ad click, because no browser click occurred. What you likely will have: an email or phone number collected as part of the agent's payment mandate or the merchant's own account system, an order ID, and a timestamp - enough for hashed-match conversion delivery on most platforms, covered platform-by-platform on the CAPI service overview.

Consent, with no cookie banner in the loop

Every CAPI event on this property is gated on recorded consent state (see ot.webclat.com for the OneTrust implementation this site cross-links throughout). A true API-only agent transaction complicates that gate mechanically: if no browser session exists, there is no cookie consent banner to have granted or denied anything. [hypothesis, an open question we have not seen settled anywhere in the current agent-commerce literature] the more defensible consent basis for a fully agent-mediated transaction is likely the payment mandate itself (the AP2 Intent/Cart/Payment Mandate chain, or the merchant's own terms accepted at account setup) rather than a website consent banner that was never shown. Do not default to "no banner, so no gate needed" - confirm the actual consent basis with counsel before wiring the event to fire unconditionally.

Dedup: the rule is different for this path

The standard CAPI discipline pairs every server event with a client-side pixel event sharing one event ID, so the platform counts one conversion, not two (see /capi/meta-conversions-api.html for the full mechanism). That rule assumes a pixel exists to pair against. For a true API-only agent checkout, there is no pixel-side event, full stop - sending a synthetic client-side event just to have something to deduplicate against does not solve a dedup problem, it invents a false page view. The server event is the only signal; treat it as already-deduplicated by construction, and confirm your ad-platform reporting shows it arriving from a server source with no matching browser-side record for the same order ID.

How to verify it worked

In the ad platform's own event diagnostics (Meta Events Manager, Google Ads' conversion diagnostics, TikTok Events Manager), confirm the event shows a server-only source for these specific order IDs - no browser-side counterpart should appear.
Reconcile total event count against your own order system's count of orders that came through the true API-only path specifically (not all agent-referred orders - see the table above). A mismatch here is the fastest way to find a webhook that silently stopped firing.
Confirm the match rate (email/phone hash match quality) on the platform side - a true API-only event typically carries less identifying data than a browser event with a full first-party cookie history, so expect a lower match rate and do not read that alone as a broken implementation.
Once the event lands and verifies, the next question is whether it is actually usable by the ad platform for attribution and optimization - that is a separate build, covered on Agent conversion signals: sending agent events to your ad platforms.