A Conversions API key is the server-side credential that authorizes your server to send conversion events straight to ChatGPT Ads, so OpenAI can attribute purchases, signups, and leads back to the ads that drove them. It is separate from the browser Measurement Pixel, which reports events from the user’s device, and separate from the Advertiser API key that manages your campaigns.
If you run conversion-optimized ChatGPT Ads campaigns, this key decides whether OpenAI ever learns which clicks turned into revenue. Skip it and your bidding optimizes toward clicks it cannot connect to outcomes, while ad blockers and closed tabs quietly erase conversions the pixel alone would have missed.
The Conversions API key functions as the authentication token on every server-to-server request your backend sends to ChatGPT Ads, proving the events came from you before OpenAI records them. OpenAI provisions the key against a single ad account, and your server attaches it as a bearer token so each batch of events is tied to the right advertiser.
The key is one of two credentials in the ChatGPT Ads stack. The Advertiser API key creates campaigns, pixels, and conversion event settings; the Conversions API key does one job, authenticating the event requests your server posts to OpenAI’s ingestion endpoint. For the key to work, a data source with a Pixel ID has to exist first, and every event you send references that Pixel ID so OpenAI knows which dataset it belongs to.
The key never touches the browser, so it stays on your server where it cannot be read from client code. AirOps generates and manages ChatGPT Ads creatives and campaigns through Playbooks, and pairs paid delivery data with the organic AI search signals teams already track.
Resources: See how to measure ChatGPT ads conversions with the pixel, the Conversions API, and a holdout test.
A Conversions API key works by signing each server event so OpenAI accepts it, matches it to an ad click, and feeds it into bidding. Here is the sequence from provisioning to attribution.
Provision the key. Using your Advertiser API key, create a Conversions API key for the ad account and keep it on your server.
Attach a data source. Reference an existing Pixel ID so OpenAI knows which dataset each event belongs to; a server-only setup still needs one.
Capture the click reference. Record the oppref identifier from the ad’s landing URL, because the Conversions API does not capture it for you.
Send the event. On a purchase, signup, or lead, post it to OpenAI’s endpoint with the key as a bearer token, a unique event ID, and the oppref.
Deduplicate and attribute. If you also fire the pixel, send the same event name and ID so OpenAI counts the action once, then credits it to the click.
The result tells you which conversions your server confirmed and ties them to campaigns, so bidding optimizes toward outcomes. It does not reveal a user’s identity or stitch together cross-device journeys; matching depends on the oppref and any hashed customer data you send.
Whether to set up a Conversions API key is really a decision about what your ad budget optimizes toward. Without server-side events, OpenAI bids on clicks and guesses at outcomes; with them, your spend chases confirmed revenue you can tie back to specific ads.
Recover conversions the browser loses. Ad blockers, privacy settings, and tabs closed before the pixel fires all drop events, and the key sends those same conversions from your server where none of that applies.
Feed conversion bidding the signal it needs. A conversion-optimized ChatGPT Ads campaign only learns from the conversions OpenAI receives, so a missing or broken key starves the algorithm and it keeps paying for clicks that never convert.
Report revenue instead of proxies. Server events carry order value, so you can compare spend against actual sales per campaign instead of settling for click counts that no finance team will accept.
SEO managers use a Conversions API key to send server-side purchase events so paid ChatGPT Ads conversions reconcile with the organic pipeline they already report on.
Growth marketers use a Conversions API key to feed confirmed signups into conversion-optimized campaigns so bidding chases qualified users instead of raw clicks.
Demand gen leads use a Conversions API key to pass CRM-validated leads back to OpenAI so attribution reflects real pipeline instead of form fills.
A Conversions API key authenticates the request, but every event also needs a Pixel ID that names the data source, and a server-only setup still has to create one even though no browser pixel is installed on any page.
When you send the same conversion from both the browser pixel and the Conversions API, OpenAI relies on a matching event name and event ID to count it once, so your server and your pixel have to agree on those values exactly.
Attribution depends on the oppref click reference and any hashed customer data your server attaches, because the key proves who sent the event but does not identify the user, so match quality rises or falls with how much data you send.
Capture server-side conversions that ad blockers and closed browsers would otherwise drop before the pixel fires.
Feed conversion-optimized ChatGPT Ads campaigns the confirmed events their bidding depends on.
Attach order value to each event so reporting shows revenue per campaign instead of click counts.
Deduplicate pixel and server events automatically through a shared event ID.
Keep the credential on your server, out of client code where it could be exposed.
Reuse one key across every server event for a given ad account.
Store the key server-side only. Keep it in an environment variable or secrets manager so it never ships in client code where anyone could read it.
Send the same event ID from pixel and server. Match the event name and ID across both paths so OpenAI deduplicates and counts each conversion once.
Capture and pass oppref on every server event. Read the click identifier from the landing URL and attach it, because the API will not capture it for you.
Send events close to real time. Post each conversion soon after it happens so it lands inside the attribution window and reaches bidding while it still matters.
Validate before you trust the numbers. Use a test or validation send and the recent-events check to confirm events arrive before you rely on reporting.
Avoid treating the Conversions API as a set-and-forget integration. The common mistake competent teams make is launching the key once, never checking that oppref survives redirects or that events still arrive, and discovering weeks later that bidding has been optimizing on a fraction of the real conversions.
AirOps: Generates and manages your ChatGPT Ads campaigns and creatives through Playbooks, connecting paid delivery to the organic AI search signals you already track so one key’s conversions sit next to the rest of your visibility data.
OpenAI Ads Manager: Provisions the Conversions API key and Pixel ID in its conversions tab and shows recent events so you can confirm your server is sending data.
Google Tag Manager (server-side): Routes conversion events from your server to OpenAI’s endpoint without custom code, keeping the key out of the browser.
Map your conversions. List the actions that count as conversions, like purchases, signups, or lead submissions, and note where your server already records each one. You can do this in an afternoon with no budget approval.
Create a data source. In ChatGPT Ads Manager, open the conversions tab and create a pixel to get a Pixel ID, even if you only plan to send server events.
Provision the key. Use your Advertiser API key to generate a Conversions API key for the ad account, then store it in your secrets manager and keep it off application code.
Wire up events. Have your server post each mapped conversion to OpenAI’s endpoint with the key, a unique event ID, the timestamp, and the oppref captured from the ad click.
Test and reconcile. Send a validation event, confirm it in the recent-events view, then compare server conversions against your own analytics before you attach the event to a campaign.
A Conversions API key is the server-side credential that authorizes your server to send ChatGPT Ads conversion events to OpenAI.
You provision it with your Advertiser API key, store it server-side, and attach it as a bearer token on every event request.
It only works alongside a Pixel ID and an oppref click reference, so authentication alone does not guarantee a matched conversion.
A leaked or missing key is the main risk: exposed, it lets others write events; absent, it starves conversion bidding.
The payoff is attribution quality, which climbs with every real conversion and identifier your server sends.
They do related jobs from different places. The Measurement Pixel is JavaScript that runs in the visitor’s browser and reports actions as they happen on your pages; the Conversions API key authenticates events your own server sends after an action is confirmed, like an order that cleared payment. The pixel is easy to install but loses data to ad blockers, privacy settings, and people who close the tab before it fires. The server path avoids all of that because it does not depend on the browser staying open or cooperating. Most advertisers run both and send the same event name and ID through each, so OpenAI recognizes the duplicate and counts the conversion once. The pixel is your fast but lossy signal; the key is your reliable, confirmed one. Used together, they give OpenAI a fuller and more accurate picture than either produces alone.
Send each event as close to real time as you reasonably can, ideally within minutes of the action. The Conversions API is not a nightly batch job by design; conversions that arrive promptly can land inside the click attribution window and reach conversion bidding while that signal is still useful for optimization. That said, the right cadence depends on your systems. If your server confirms orders instantly, fire the event on confirmation. If a conversion is only validated later, for example a lead your sales team qualifies in a CRM, send it when the status changes and include the original timestamp so OpenAI knows when it actually occurred. Avoid holding events for long stretches, because very old events may fall outside the window and stop counting. A simple rule works well: send on the event, retry on failure with the same event ID, and never wait for a scheduled export when you do not have to.
Some gap is normal and expected. OpenAI’s reported conversions and your internal analytics count different things in different ways, so the two rarely match to the number. Platform totals can include modeled conversions that estimate activity the raw events did not capture, while your analytics typically count only what it directly observed. Attribution windows differ too: OpenAI credits a conversion to a click within a set window, and your last-click analytics may assign the same sale somewhere else entirely. Deduplication between the pixel and the server also shifts counts if event IDs do not line up. The practical move is to pick one source of truth for each decision before you launch instead of trying to reconcile every figure. If the two numbers diverge wildly, investigate deduplication and whether oppref is surviving your redirects, because a large gap usually points to a setup problem instead of normal variance.
Yes, and this is one of the few parts of attribution you directly control. The key authenticates the request, but match quality comes from what you put inside each event. The single biggest factor is the oppref click identifier: capture it from the landing URL, preserve it through every redirect, and attach it to the server event, because the API will not add it for you. Beyond that, send supported customer information as properly normalized and hashed values, which gives OpenAI more ways to connect an event to a click when oppref is missing. Keep event IDs consistent with your pixel so deduplication works, and send accurate timestamps so events land in the right window. Each of these is a deliberate choice in your server code, so better matching is mostly a matter of sending more complete, correctly formatted data every time.
A healthy setup is one where nearly every real conversion reaches OpenAI, arrives quickly, and matches to the right click. In practice, check a few things. Your server events should show up in the recent-events view within minutes of a test action, confirming the key and endpoint work. The share of conversions carrying an oppref should be high, since those match most reliably, and server and pixel counts for the same event should be close once deduplication is accounted for. Your server-reported conversions should meet or modestly exceed what the browser pixel alone captured, because the whole point is recovering events the browser missed. There is no universal benchmark number, so judge against your own baseline: track your matched-conversion rate over time and treat a sudden drop as a signal that oppref capture, redirects, or the key itself has broken. Stable, promptly delivered, well-matched events are the real standard.