The X, formerly Twitter, Conversion API is the least-documented of the major platforms, but if you still run X ads, it's how you send server-side conversions the pixel can't be trusted to deliver.
What you're connecting
The X Pixel fires in the browser and captures the click id, twclid. Your server sends a matching event to the Conversion API with a shared conversion_id, so X deduplicates the pair.
It's the same pattern as every other platform here, with different field names and thinner docs.
Setup, step by step
- Install the X Pixel and confirm it fires your key events in the browser.
- Capture the twclid on the landing page and store it for the server call.
- Send server events with a conversion_id that matches the pixel event.
- Include the twclid and hashed email or phone, plus the real IP and user agent.
The payload looks roughly like this, with field names following X's current API:
{
"conversions": [{
"conversion_id": "order_10432",
"identifiers": [
{ "twclid": "<twclid>" },
{ "hashed_email": "<sha256_email>" }
],
"value": "49.00",
"currency": "USD",
"conversion_time": "2026-09-13T10:00:00Z"
}]
}
Deduplication and matching
The conversion_id joins the pixel and server events, so keep it identical on both sides, ideally your order id. The twclid is what lets X tie the conversion to a specific ad click, so capturing it is not optional.
Where it breaks
- The twclid was never captured, so matching falls back to email alone.
- The conversion_id differs between pixel and server, so both count.
- Identifiers sent unhashed, which the API rejects.
- A malformed conversion_time, so X can't place the event.
A reality check
X's ad platform and documentation have moved a lot, so verify field names and endpoints against the current docs before you build. The concept is stable even when the details aren't.
Where to run it, and whether to bother
As with the others, send the X event from your backend, from server-side GTM, or from a connector. If you already run a server container for Meta and TikTok, add X there rather than building something separate.
The honest question is whether X ad spend justifies the work. If you spend meaningfully on X, the server-side copy is worth it, because the pixel alone loses the same share of events it loses everywhere. If X is a rounding error in your budget, the pixel is probably enough.
Matching realities
X matching leans hard on the twclid, more than on hashed identifiers, so capturing the click id is the difference between decent and useless attribution. Store it the moment someone lands from an X ad, and carry it through to the conversion.
Hashed email and phone help, but they're the backup, not the primary key.
What good looks like
Conversions arriving from both the pixel and the server, deduplicated on the shared conversion_id, with the twclid present on the server events. Fire a real conversion, confirm those three, and only then trust the numbers in the X dashboard.
Re-verify after any platform update, because X changes more than the others and a silent field rename can break you.
Budget the maintenance honestly. X asks for the same server-side discipline as the bigger platforms but returns less traffic, so keep the setup simple and the checks automated rather than hand-tending an integration for a minor channel. Automated and boring beats clever and brittle, especially for a channel you only glance at occasionally.
The X Conversion API is under-documented but not different: a server-side copy, a shared conversion_id, and the twclid for matching. Capture the click id, share the id, hash the rest, and X stops losing the conversions the browser drops.
Want a stronger data analyst role or a raise? Grab the FREE Product Analyst Playbook and get the exact roadmap to your next offer.
