When Does the OpenAI Conversions API Beat the Pixel?

Last verified: 12 September 2026 | Version: 1.0 | Next scheduled review: 12 October 2026

The Conversions API beats the pixel in exactly three situations: the conversion happens somewhere a browser is not, the browser event is being blocked, or the conversion needs to carry information the browser does not hold. For most B2B advertisers the honest answer is that it is engineering work you should not do yet, and the reason is a seven day limit buried in the field spec.

What the API is

A server-side POST that sends conversion events to the same Pixel ID your browser pixel uses.

curl -X POST "https://bzr.openai.com/v1/events?pid=<PIXEL-ID>" \
  -H "Authorization: Bearer <API-KEY>" \
  -H "Content-Type: application/json" \
  --data '{ "validate_only": false, "events": [] }'

The API key is created through POST /v1/conversions/api_keys and is a server-side secret. A batch carries up to 1,000 events. Setting validate_only to true checks a payload without recording anything, which is the right way to build the integration.

Each event carries an id, a type drawn from the same supported event list the pixel uses, a timestamp_ms, an action_source of web, mobile_app or offline, and a data object matching the event's shape. Optional fields include oppref, source_url, opt_out and a user object.

The seven day rule, which decides most of this

timestamp_ms must fall within the last seven days, and no more than ten minutes in the future. OpenAI's Conversions API documentation states this as a validation constraint, and a batch is rejected in full if any single event in it fails validation.

Read that against the thing most B2B advertisers want the API for. A lead arrives on Tuesday. Sales qualifies it eleven days later. The deal closes in November. None of those later events can be sent with their real timestamp, because the real timestamp is outside the window.

You have two options and both are compromises. You can send the event with a timestamp inside the window, which is a truthful conversion carrying a false date and will misplace your daily reporting. Or you can send the qualifying event only when it happens inside seven days of the original action, which discards the slow half of your pipeline, which is the half you were trying to measure.

Neither is a reason to skip server-side entirely. It is a reason to stop describing the Conversions API as the fix for long B2B sales cycles, which is how most write-ups in this category describe it.

The identity problem, and oppref

The pixel captures oppref from the landing page URL automatically and stores it in a first-party cookie. The Conversions API captures nothing. If you send a server event without oppref, OpenAI has to fall back on the hashed identity fields, and if you send neither, the event arrives unattributable.

So the first piece of engineering is not the API call. It is capturing oppref at the landing page, carrying it into your form as a hidden field, storing it on the record in your database or CRM, and retrieving it when the server event fires. That chain is where server-side implementations break, and it breaks silently: Ads Manager simply shows fewer conversions than your CRM does.

On 16 July 2026 OpenAI added events[].user.obref, a pixel browser reference that can be passed in Conversions API requests, giving a second join path where the pixel has run but no click reference survived.

The user object also accepts emails_sha256, phone_numbers_sha256 and external_ids_sha256, plus countries, cities, postal_codes, ip_address and user_agent. Hashed values must be normalised before hashing, that is trimmed, lowercased, punctuation removed where it applies, then SHA-256 over UTF-8. Normalise wrongly and the hash is simply a different string that matches nothing, with no error to tell you.

Deduplication

If the same conversion goes out from both the browser and the server, reuse the same value for the pixel's event_id and the API's id. OpenAI deduplicates on Pixel ID, event name and event ID, and processes only the first event received.

The practical rule: use a natural key you already have. An order number. A CRM record ID. A form submission UUID written before the redirect. Anything randomly generated at fire time cannot match across two systems.

When server-side actually earns its cost

Four cases, in descending order of how often they apply.

The conversion has no browser. A phone call booked through an inbound line, a contract signed in a document tool, an app install. action_source: "offline" and mobile_app exist for exactly this, and there is no browser alternative.

The browser event is unreliable. Ad blockers, Safari's restrictions on script-written storage, an in-app browser stripping context. Server-side recovers events that would otherwise vanish. Nobody has published a ChatGPT-specific recovery rate, and the recovery rates quoted in this category are borrowed from Meta.

The conversion needs data the browser does not have. Deal value known only after finance touches it, a lead scored after enrichment, a subscription whose real value is the annual contract rather than the first month.

You want to send a different event than the one the user saw. This is the real B2B case: reporting lead_created teaches the bidder to buy form fills, reporting a qualified lead teaches it to buy pipeline. Subject to the seven day rule above.

The honest recommendation at this spend level

The minimum daily budget on ChatGPT Ads is 25 USD, and bid guidance circulating through 2026 has sat at three to five USD CPC, reported rather than published by OpenAI. An advertiser at a thousand dollars a month is buying something like 200 to 330 clicks. A server-side integration, done properly, is a backend endpoint, an oppref capture chain through a form and a CRM, a hashing and normalisation layer, a retry queue, and a test suite, plus the ongoing maintenance of all of it.

That work is worth doing when the channel is already proven and you are optimising it. It is poor sequencing when the open question is still whether the channel serves your category at all. The cheaper version of the same answer: install the pixel, tag your URLs, capture oppref into your CRM as a field, and read pipeline quality manually for the first quarter. You will learn the same thing, later, for a tenth of the cost.

The counter-argument deserves stating. Conversion-optimised campaigns bid against the event you report, so an advertiser sending only form fills is training the bidder on a signal they know is wrong, and every week of that is money spent learning the wrong lesson. If your form fill to qualified lead rate is genuinely poor, that argument wins, and server-side becomes worth doing early. If it is decent, it does not.

What we cannot tell you

• How much delivery improves when the reported event is a qualified lead rather than a form fill. No advertiser has published a controlled comparison and we have no account to run one in.
• The event recovery rate from server-side on this channel. Unpublished. Figures circulating are transferred from other platforms.
• Whether a timestamp shifted into the seven day window affects attribution quality or only reporting dates. Undocumented.
• Whether OpenAI plans a longer ingestion window for offline events. Not on any published roadmap.
• How modelled measurement treats server events with hashed identity but no click reference. OpenAI mentions modelled measurement without describing the model.

Quick answers

What is the OpenAI Conversions API? A server-side endpoint at bzr.openai.com/v1/events that sends conversion events to your Pixel ID from your backend, with bearer token auth and batches of up to 1,000 events.

Can I send offline conversions weeks after the click? Not with their real date. Event timestamps must fall inside the last seven days, so a deal that closes in week six cannot be sent with a week six timestamp.

Do I need the pixel if I use the Conversions API? In practice yes. The pixel is what captures the oppref click reference and stores it, and the API does not capture anything by itself.

How do I avoid double counting? Send the same value as the pixel's event_id and the API event's id. Deduplication runs on Pixel ID, event name and event ID, and the first arrival wins.

What identity data does the API accept? SHA-256 hashed emails, phone numbers and external IDs, plus country, city, postal code, IP address and user agent. Normalise before hashing or the value matches nothing.

Should a 1,000 USD a month advertiser build this? Usually not yet. Prove the channel with the pixel and CRM fields first. Build server-side when you are optimising a channel that already works.

Sources

Related reading

• How to Install the OpenAI Ads Pixel, Directly or Through GTM
• Pushing ChatGPT Ads Data Into Your CRM and Scoring Lead Quality
• What OpenAI's Attribution Windows Actually Count
• How to Measure ChatGPT Ads, and What You Cannot Measure Yet
• ChatGPT Ads Bidding

Changelog

12 September 2026, v1.0. First publication. Documents the seven day ingestion limit as the constraint that breaks the standard offline-conversion argument for server-side on this channel.

Field kit

Tools

• Eligibility Checker
• Budget Calculator
• OAI-AdsBot Checker
• Context Hints Generator
• Buy Scorecard

Site

• ChatGPT Ads
• Google AI Mode Ads
• Methodology
• Glossary
• Contact

OpenAI (primary)

• ChatGPT Ads Help Center
• Ads in ChatGPT: The Basics
• Measure Results
• Ad Policies
• Ads Manager
• OAI-AdsBot verification