Skip to content

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.

The customer's browser shops on the WooCommerce store. In the browser, the Measurement Pixel sends product views, add to cart, checkout starts and the purchase to OpenAI. When WooCommerce marks the order paid, the plugin sends the purchase from the server to the OpenAI Conversions API. OpenAI deduplicates the two purchases by event ID.

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).

Key fields of a Conversions API purchase event
FieldWhat it carries for a WooCommerce purchase
event_nameorder_created — a completed purchase
idThe event ID. Must match the browser event for the same order.
timestamp_msWhen the purchase happened, in milliseconds.
action_sourceweb 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.
  1. Checkout completed

    Order created in WooCommerce

  2. Payment confirmed

    Order reaches a paid status

  3. Purchase sent

    order_created from your server

  4. 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.

The browser purchase and the server purchase for the same order carry the same event ID. OpenAI keeps the first one it receives and ignores the duplicate, so the order counts as one conversion.

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:

Kinds of delivery failure and how to treat them
FailureExampleTreatment
TemporaryTimeout, rate limit (429), server error (5xx)Retry automatically with the same ID
ConfigurationRejected API key (401)Fix the setting, then re-send
NetworkServer cannot reach the APIFix 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.

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:

Server-side purchase handling in Pixel for ChatGPT Ads
ConcernBehaviour
Event sent server-sideorder_created only
TriggerThe order reaches a paid status in WooCommerce
Event IDDerived from the order; the same ID as the browser purchase
Purchase timeThe original purchase time is sent
Temporary failuresRetried automatically
VisibilityDelivery state, attempts and HTTP status per order
Manual retryAvailable for eligible orders once the cause is fixed
API keyStored for server-side use; never printed into the page
ConsentUses the consent state recorded for the order (WordPress Consent API)
Order storageHPOS and legacy order storage both supported

The server-side purchase path, as the plugin implements it.

  1. 1The paid WooCommerce order is the starting point — not the shopper's browser.
  2. 2The purchase travels from your store to the OpenAI Conversions API.
  3. 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.