Guide
OpenAI Conversions API for WooCommerce
The OpenAI Conversions API lets a WooCommerce store send ChatGPT Ads conversions from its own server instead of the shopper's browser. For a store, the conversion that matters most is the purchase: once WooCommerce marks an order paid, the order exists whether or not a browser script reported it. This guide explains how server-side purchase tracking works, what a correct implementation has to handle, and what it cannot fix.
Updated
On this page
In one paragraph: send order_created from WooCommerce when the order reaches a paid status, with the same event ID the browser pixel used for that order, the original purchase time, and your API key kept on the server. Retry temporary failures with the same ID, and keep a record of what happened to each order.
Architecture
Server-side purchase tracking at a glance
Two paths leave the store. The browser path carries the whole buying journey; the server path carries the paid order.
In the browser, the Measurement Pixel sends product views, add to cart, checkout starts and the purchase. When WooCommerce confirms a paid order, the purchase is also sent from your server through the OpenAI Conversions API, with the same event ID, so OpenAI can count it once.
Customer's browser
Views products, adds to cart, checks out
WooCommerce store
Products, cart, checkout and orders
In the browser
Measurement Pixel
contents_viewed, items_added, checkout_started, order_created
OpenAI
Receives browser events
On your server
Order marked paid
WooCommerce status change
Plugin sends order_created
Same event ID · retries · diagnostics
Conversions API
Authenticated with your API key
One purchase counted
OpenAI matches Pixel ID, event name and event ID, and ignores the later duplicate.
What browser measurement misses
The Measurement Pixel runs in the shopper's browser. That is the only place that can see product views and cart activity, but it also means an event is lost whenever the page or script does not run to completion:
- Content blockers or privacy tools stop the pixel script from loading.
- The customer closes the tab after paying, before the order-received page loads.
- A payment is confirmed later — bank transfer, some redirect gateways — when the customer is no longer on the site.
- A slow or failed page load drops the request.
In each case WooCommerce still records the order. A server-side purchase event starts from that order, so none of these stop it from being sent.
How the Conversions API works
Your server makes an authenticated HTTPS request to OpenAI with one or more events. The request is addressed by your Pixel ID and authorised with a Conversions API key, both provisioned in the conversions tab of Ads Manager (OpenAI Conversions API documentation).
| Field | What it carries for a WooCommerce purchase |
|---|---|
event_name | order_created — a completed purchase |
id | The event ID. Must match the browser event for the same order. |
timestamp_ms | When the purchase happened, in milliseconds. |
action_source | web for an online store |
Server only
OpenAI says to send events to the Conversions API from your server only
, and the Pixel documentation adds: do not call the server API directly from page code
. The API key must never reach the browser.
When to send the purchase
Send it when WooCommerce moves the order to a paid status — not when the order-received page renders. Tying the event to the order status rather than a page view means:
- It fires once per order, however many times the thank-you page is reloaded.
- Delayed payment methods send the purchase when the payment is actually confirmed.
- Unpaid, failed or abandoned orders are not reported as purchases.
Checkout completed
Order created in WooCommerce
Payment confirmed
Order reaches a paid status
Purchase sent
order_created from your server
Outcome recorded
Accepted, retried or failed
Event IDs and deduplication
If a purchase is sent from the browser and from the server, OpenAI needs a way to know it is one purchase. OpenAI documents that for deduplication, OpenAI uses your Pixel ID, event_name, and id
, and that it uses the first event it receives for a matching key and ignores later duplicates.
So the event ID has to be identical on both paths. The reliable way to do that on WooCommerce is to derive it from the order, which both the order-received page and the server know, rather than generating a random ID in the browser that the server never sees. The Pixel vs Conversions API guide covers how the two paths fit together.
Browser · Pixel
Purchase
Shared event ID derived from the WooCommerce order
Server · Conversions API
Purchase
Shared event ID derived from the WooCommerce order
One conversion
Same Pixel ID, event name and ID: OpenAI keeps the first and ignores the duplicate.
The 7-day rule
OpenAI rejects events outside a time window: The timestamp must be within the last 7 days and no more than 10 minutes in the future.
Two consequences for a store:
7 days
oldest accepted purchase time
10 minutes
furthest into the future
- Send the original purchase time, not the time of the attempt — otherwise a retried event claims the purchase happened later than it did.
- Fix failed deliveries promptly. An order whose purchase time is more than 7 days old can no longer be sent.
The API also accepts batches of up to 1,000 events, and if one event in the batch fails, the full batch fails
— one malformed order can block others if an implementation batches carelessly.
Retries and failures
OpenAI's documentation tells you to reuse the same ID when retrying or sending the same conversion through another integration
. It does not publish a retry schedule, so the policy is up to the implementation. A sensible one separates:
| Failure | Example | Treatment |
|---|---|---|
| Temporary | Timeout, rate limit (429), server error (5xx) | Retry automatically with the same ID |
| Configuration | Rejected API key (401) | Fix the setting, then re-send |
| Network | Server cannot reach the API | Fix outbound HTTPS or firewall rules |
Whatever the policy, a failure has to be visible somewhere. Without a per-order record, a broken integration looks exactly like a quiet week of sales.
Consent
Server-side delivery is not a way around consent. The Pixel itself does not send measurement pings when consent is false (Measurement Pixel documentation), and a server-side purchase should respect the consent state recorded for that order. On WordPress, the WordPress Consent API is the common way for a consent banner to share that state with other plugins.
How Pixel for ChatGPT Ads implements it
Pixel for ChatGPT Ads is a WooCommerce plugin that sends only the purchase server-side. Here is what it does at each point above:
| Concern | Behaviour |
|---|---|
| Event sent server-side | order_created only |
| Trigger | The order reaches a paid status in WooCommerce |
| Event ID | Derived from the order; the same ID as the browser purchase |
| Purchase time | The original purchase time is sent |
| Temporary failures | Retried automatically |
| Visibility | Delivery state, attempts and HTTP status per order |
| Manual retry | Available for eligible orders once the cause is fixed |
| API key | Stored for server-side use; never printed into the page |
| Consent | Uses the consent state recorded for the order (WordPress Consent API) |
| Order storage | HPOS and legacy order storage both supported |
The server-side purchase path, as the plugin implements it.
- 1The paid WooCommerce order is the starting point — not the shopper's browser.
- 2The purchase travels from your store to the OpenAI Conversions API.
- 3Blocked scripts, closed tabs and content blockers do not stop this path.
Product views, add to cart and checkout starts stay browser events. The ChatGPT Pixel for WooCommerce overview lists every event and where it is sent from.
Expectations
What server-side tracking helps with, and what it does not solve
Server-side delivery makes the purchase more reliable. It is not a fix for everything.
What server-side tracking helps with
- Purchases whose browser event was blocked by a content blocker.
- Customers who close the tab after paying.
- Payments confirmed later, when the customer has left the site.
- Seeing, retrying and re-sending failed deliveries per order.
What it does not solve
- It does not decide attribution. Whether a purchase is credited to a ChatGPT ad is determined by OpenAI, not by how the event was delivered.
- It does not recover browser-only events. Product views and cart activity still need the browser.
- It does not override consent. Orders without marketing consent are not sent.
- It does not fix a second, unmanaged pixel. Duplicate copies without shared IDs still double-count.
- It does not guarantee every conversion. It removes the browser as a single point of failure for the purchase.
Questions
Is the Conversions API required for ChatGPT Ads?
OpenAI supports measuring conversions with the Pixel, the Conversions API or both (conversion tracking overview). For a store, sending the purchase through both with a shared ID gives it a path that does not depend on the browser.
Can I call the Conversions API from JavaScript on the thank-you page?
No. It would expose your API key and still depend on the browser. OpenAI says to use the Pixel in the browser and the Conversions API from the server.
Does server-side tracking need Google Tag Manager server containers?
No. WooCommerce runs on a server already; a plugin can send the purchase from WordPress directly.
Does this plugin send add to cart server-side?
No. Only the purchase is sent server-side. The other three events are browser events.
Server-side purchases without building the integration
Pixel for ChatGPT Ads handles the trigger, event IDs, retries and per-order diagnostics for WooCommerce. Same functionality on every plan.
Related guides
- ChatGPT Pixel for WooCommerceWhat the plugin sends to ChatGPT Ads from a WooCommerce store, how it is set up, and what it does not do.
- ChatGPT Ads Pixel vs Conversions APIA side-by-side comparison of browser and server measurement for ChatGPT Ads, and why a store uses both.
- How to install the ChatGPT Ads pixel on WooCommercePrerequisites, where the Pixel ID and API key come from, configuration, and how to verify the first order.