X Conversion API: server-side conversions, no code

#Quick answer

The X Conversion API is a server-to-server endpoint that reports conversions the X Pixel never sees: POST to ads-api.x.com/12/measurement/conversions/{pixel_id} with a time, an Events Manager Event ID, and at least one matchable identifier. Since 17 September 2026 there is an official Google Tag Manager server tag that does it with no code, no OAuth and no Ads API access. Run it alongside the Pixel and share a Conversion ID so X can deduplicate.

Last updated: October 2026

Most guides to this still open with "apply for Ads API access and set up OAuth 1.0a", which is now wrong for the route most advertisers should take. X published an official GTM server-container template in September 2026 that authenticates with a token you generate in Events Manager. That changes who can do this from "a developer with API credentials" to "whoever owns your tagging server".

#Why the Pixel alone undercounts

The X Pixel fires in a browser, which means it misses a predictable set of conversions: anything completed after a redirect off your domain, anything finished on a different device from the ad click, anything an extension or a tracking-prevention default blocks, and anything that happens in your backend rather than on a page. Phone orders and offline closes never had a chance.

Undercounting is not only a reporting annoyance. Campaign delivery optimizes against the conversions it is told about, so a channel that reports 60% of purchases is also training on 60% of them. That is the real argument for server-side reporting, and it is the one X leads with: measure when browser tracking is limited, and optimize delivery better.

Server-side reporting sits next to the Pixel rather than replacing it. X's recommended setup is explicitly redundant, with both channels sending the same events and a shared key so duplicates collapse.

#Two routes in, and they have different entry requirements

This is the part worth getting straight before you plan the work, because the two paths are not equally hard.

If you already run server-side GTM, the official tag is the short path and the only credential you need comes from Events Manager: Install Pixel → Manual → Conversion API → Generate access token. Store it in a GTM variable rather than pasting it into several tags.

One warning from X's own documentation that is easy to miss: use the template named X Ads Conversion API (Official). Community templates with similar names, including third-party "X (Twitter) Conversion API" tags, are a different integration with different authentication.

#Event ID and Conversion ID: the two IDs people mix up

This is the single most expensive misunderstanding in the whole setup, and X calls it out directly.

• Event ID is the conversion type. It comes from Events Manager and identifies, for example, your Purchase event.
• Conversion ID is the per-occurrence deduplication key. An order number, a UUID, or the GA4 event_id.

To deduplicate between the Pixel and the Conversion API you need both to match on both channels: the same Event ID and the same Conversion ID for the same conversion. Matching only the Event ID tells X the two reports are the same type, not the same purchase, and you get double counting. The clean way to guarantee it is to fire the Pixel tag and the GA4 event tag from the same trigger in the web container, with one generated ID shared between them.

If the Pixel and the API send genuinely different events, skip all of this. Deduplication is only needed where the two overlap.

There is also a quiet fallback worth knowing. If you leave Event ID empty on the GTM tag, it sends the incoming event name prefixed and lowercased, so purchase arrives as gtm_purchase. Convenient for a single catch-all tag. Bad for Pixel deduplication, because those are not your Events Manager events. And if both the Event ID and the event name are missing, the conversion is not sent at all, silently.

#Identifiers: what actually matches

X needs at least one identifier it can tie to an account. The rules are specific and the hashing is unforgiving.

Two failure modes account for most poor match rates. The first is hashing done wrong: a salt, a stray space, or an uppercase address produces a hash that will never match. The official GTM tag will hash plain values for you, which removes that class of bug, and it passes through any value that is already a 64-character hex string.

Second is a lost click ID. X appends twclid to the landing page URL on an ad click, and it only survives to the conversion if something stores it. With Set first-party cookies enabled, the server tag writes a _twclid cookie that lasts about 390 days. That cookie is far more durable on a first-party tagging domain than on the default one, which is why mapping a custom domain to your tagging server is not cosmetic. If you keep the Pixel installed, it also sets _twpid, which the server tag reads as another identifier.

Passing more identifiers raises the match rate. Passing only IP and user agent raises nothing, because neither counts alone.

#The GTM path, condensed

Structurally it is a web container feeding a server container, with the X tag firing on the server side.

1. Collect three things from Events Manager: the Pixel ID, which is your event source ID, the Event ID for each conversion you care about, and a Conversion API access token.
2. Create a server container and provision a tagging server. Keep the default GA4 Client enabled, because it claims the incoming requests the X tag reads.
3. Point the web container at it. In your GA4 Configuration tag, enable sending to the server container or set the transport_url field to your tagging server URL. Add first_party_collection: true so hashed user data reaches the server.
4. Install the official tag in the server container from Templates → Search Gallery.
5. Configure it: Pixel ID, access token from a variable, and the Event ID for this conversion. One tag per Events Manager event is the cleaner pattern when you care about named events.
6. Trigger on the event name that the GA4 Client claimed, for example purchase, rather than on all requests.
7. Preview both containers before publishing. The checks that matter are that the GA4 Client claimed the request, that the X tag fired, that its outgoing POST went to ads-api.x.com, and that the response was 2xx. Then confirm the conversion appears in Events Manager.

Set the tag's logging to debug only while testing and switch it off for production. X notes that logs can include identifiers, which is not something you want written to a console on live traffic.

#What quietly fails, and the ceiling

Three things are worth writing on a sticky note.

A failed call is a lost conversion. X tells you to check the response code and build retries with logging. There is no queue on their side holding your 500s. A success returns conversions_processed and a debug_id, and that debug ID is the thing to quote if you ever open a support thread.

The rate limit is 60,000 events per ad account per 15 minutes. Generous for most advertisers, and a real constraint for a batch backfill, which is the scenario where people hit it.

Consent is your problem, not the tag's. X states plainly that your server code may need to filter out conversions from users who exercised privacy choices, and the GTM guide repeats it. Server-side reporting removes the browser from the path, which also removes whatever consent gate lived in the browser. That logic has to be rebuilt deliberately on your side, and X's conversion tracking and custom audiences policies are the governing document for what you are allowed to send.

#Is it worth the afternoon?

If you are spending enough on X ads that a 20% reporting gap changes a decision, yes, and the GTM route makes it a configuration job rather than an engineering one. Better conversion data also makes the rest of your X ads cost math honest, since cost per acquisition is only as good as the denominator. If you are running lead gen ads, the native form already reports inside X, so the Conversion API matters most for what happens on your own site afterward.

If you are not buying ads at all, none of this applies to you, and the measurement question is a different one. Organic reach on X is decided by the algorithm rather than by a pixel, which is why how an X post accumulates views and what an X ad actually is are more useful starting points than a tagging server. Our own tool, X-Autopilot, sits on that organic side: it runs on your Mac for replies and posting cadence, and it has nothing to do with ad measurement.

The honest summary of the September change is narrow but real. The Conversion API did not get easier to understand. It got easier to install, for exactly one kind of advertiser: the one who already has a tagging server and was told, incorrectly, that they needed API credentials first.