X Conversion API: the two endpoints and what differs

#Quick answer

The X Conversion API is now two endpoints. Web conversions go to ads-api.x.com/12/measurement/conversions/{pixel_id} with an X-Pixel-Token header. App installs and in-app events go to /12/accounts/{account_id}/measurement/app_conversions with an X-App-Conversion-Token header, added 29 October 2026. They take different field names, different timestamp formats, and the app one has no deduplication key.

Last updated: November 2026

Two changes in two months reshaped this product. In September 2026 X published an official Google Tag Manager server-container tag, which turned the web route from an engineering job into a configuration job. In October 2026 X split the product in half: the original endpoint was renamed Conversion API for Web and a separate Conversion API for App Events appeared next to it. Most guides describe neither.

#Why the Pixel alone undercounts

Browser-side tracking misses a predictable set of conversions. The X Pixel fires in a page, so it never sees 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.

#App events got their own endpoint, with a narrower object

Before 29 October 2026, reporting an app install to X meant working through a mobile measurement partner. The Conversion API for App Events removes that dependency: you connect the app in Events Manager under Manage App Events → X App Conversion API, generate a token, and POST events from the app or from your server.

Connecting is the step that creates something. X creates the app's INSTALL event for you, with a 14-day post-engagement and 1-day post-view attribution window that you can change afterwards. Extra event types such as SIGN_UP and PURCHASE are added in Events Manager and then sent with the same request shape.

Side by side, they look similar and are not interchangeable:

Read the last three rows together, because they decide what you can do with this.

No conversion_id means no deduplication. The whole discipline described above, matching a per-occurrence key across two channels, has no equivalent on the app side. If you keep an MMP running during a migration, both will report the same install and X has no key to collapse them. Run one or the other per app, and cut over rather than overlap.

No value means no revenue optimisation through this endpoint. Web conversions carry value, number_items and an itemised contents array. An app PURCHASE event carries a name and a timestamp. You can tell X that a purchase happened, not what it was worth.

No twclid either, which follows from the medium: there is no landing-page URL to parse. App identifiers are device_id, hashed_email, hashed_phone_number, or ip_address paired with user_agent, plus an optional limit_ad_tracking flag.

One asymmetry in the hashing rules is worth noticing. Email and phone must be SHA-256 with no salt, same as the web endpoint, but device_id is the raw, unhashed IDFA or Android Advertising ID. X names device_id as the recommended identifier, and on iOS that means an App Tracking Transparency prompt in the app, so the recommended path is also the one that needs an app release and a user's consent. If you would rather not ship that change, hashed email or hashed phone works without touching the app.

Finally, two operational notes. The token is shown only once, and one token covers every app on the ad account, so treat it like an account-wide credential rather than a per-app one. And the response is the same shape as the web endpoint, conversions_processed plus a debug_id, which is the value to quote in a support thread.

#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 web ceiling 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. X publishes no rate limit for the app endpoint, only the 500-conversion cap per request, so pace a backfill there against the web number until something tells you otherwise.

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.

Honest summary of the September change: 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.