You have already wired up Meta, LinkedIn, TikTok, Snapchat, and Pinterest through the Conversions API, and one platform is still sitting on the bench: X (Twitter). It is the obvious missing piece, and also the least well documented. The good news: setting up the X Conversions API in server-side GTM takes a few minutes with the right template. The real question, the one that decides the quality of your signal, comes down to two settings: deduplication via conversion_id between the client-side X pixel and the server, and the match score, which relies above all on an identifier few advertisers capture correctly, the twclid. This article skips the generic walkthrough and goes straight to those two points, with one simple goal: walk away with a clean setup, no duplicate conversions, and maximum matching for the X Ads algorithm.
Why move X CAPI server-side in 2026
The browser-side X pixel suffers from the same ailments as all the others. Ad blockers stop the tag from firing on a growing share of sessions, Safari ITP shortens the lifespan of first-party cookies to seven days, and consent refusal rates often cap collection at half of your real traffic. The concrete result: depending on the audience, 30 to 45% of your conversion signal never reaches X. The bidding algorithm then optimizes on truncated data, and you pay more for every attributed conversion.
The X Conversions API in server-side GTM answers this by sending events directly from your server container to the X API, without depending on the visitor’s browser. You recover volume, you recover richer user data, and you regain control over what actually leaves for the ad platform. This is exactly the logic already described for the other platforms in the Meta CAPI server-side GTM guide, transposed to the X ecosystem.
An honest caveat: X CAPI only makes sense if you already run a GTM server for other channels. Standing up and paying for a server container for X Ads alone is only worth it when your spend on the platform is significant. If you are starting from scratch on server-side, read why and how to migrate to server-side GTM first: the infrastructure logic matters more than the tag itself.
Recommended architecture: client-side X pixel plus server-side CAPI tag
The classic mistake is to treat the CAPI as a replacement for the pixel. It is not. X, like Meta, recommends running both channels in parallel: the browser-side X pixel for responsiveness and coverage of the signals available in the page context, and the Conversions API on the server for reliability and resistance to blockers. The two sources complement each other rather than replace each other.
So the target setup is this: the X pixel stays loaded on the site for standard events (PageView, purchase, and so on), and your server container sends the same events in parallel through the CAPI. Data reaches X through two paths, which maximizes the odds that at least one gets through. But as soon as the same event arrives twice, you have to tell X to count it only once. That is the whole point of deduplication.
Deduplication: the central role of conversion_id
With no wiring, running the pixel and the CAPI in parallel mechanically produces double counting: every purchase reports twice, your ROAS inflates artificially, and the algorithm learns on false numbers. Deduplication fixes this.
On X, the deduplication key is called the conversion_id. The principle is simple: for a given event, you send a unique identifier that is strictly identical in the client-side pixel and in the server-side CAPI call. When X receives two events carrying the same conversion_id, it understands they are the same action and keeps only one.
Three pitfalls come up consistently, and they hold for X just as they do for the other platforms in the series:
| Pitfall | Consequence | Fix |
|---|---|---|
conversion_id differs between pixel and server | Full double counting, inflated ROAS | Generate the ID once and share it with both channels |
| ID regenerated on every page reload | Deduplication impossible for the same event | Set the ID at event time and freeze it in the data layer |
| Server event sent outside the matching window | X can no longer pair the two | Send the server event with no abnormal delay |
That last point deserves a note: X reconciles events received within a 48-hour window. In practice, with an immediate server-side send, you are never close to that limit. The risk only appears when you replay conversions in batch with a large lag. The golden rule stays the same: a conversion_id generated once, propagated identically to both sources. It is the same discipline detailed for Pinterest CAPI, where a single key, the event_id, plays exactly this role.
The twclid: X’s real differentiator
Here is the point most tutorials gloss over, and it is precisely where the quality of your signal is decided. To attribute a conversion to an ad click, X needs to pair the event with a user. It accepts several identifiers for this, but they are not equal. The most reliable by far is the twclid, the X Click ID. It is the exact equivalent of Meta’s fbclid or Google Ads’ gclid.
Concretely: when a user clicks your X ad, the platform appends a twclid parameter to your landing page URL. That parameter is a deterministic link between that specific click and the session. If you capture it and send it back as is in the CAPI call, X makes a direct, certain match without falling back on probabilistic signals. It is the cleanest matching possible.
The problem is that this twclid is very easy to lose. It is only present in the URL of the first page after the click. If you do not capture it immediately, navigating to another page wipes it, and you will never be able to send it back at purchase time. Correct implementation comes in three steps:
- Capture the
twclidparameter as soon as the visitor lands on the site, in the page load context. - Store that value in a durable first-party cookie, ideally set server-side so it survives Safari ITP.
- Send the stored
twclidin every CAPI conversion event, reading it back from the cookie.
Without this chain, your match quality collapses and you fall back on far less precise signals. This is X’s technical differentiator versus the other platforms: elsewhere, the hashed email often carries most of the matching; on X, the twclid is king.
The other matching signals
The twclid is the priority signal, but it does not cover 100% of cases: a user can convert from a session where the X click is old, or from a different device. So X requires at least one matching identifier per event, and you have every interest in stacking several to lift your match rate.
The accepted identifiers, in order of reliability, are: the twclid, the SHA-256 hashed email, and the hashed phone number in E.164 format (country code included, no spaces or plus sign). X also accepts the IP address and user agent, but those two are not enough on their own: they must accompany a stronger identifier to be used. Personal data is hashed server-side, before sending, which is precisely one of the privacy strengths of server-side.
The rule is cumulative: the more valid identifiers you send per event, the higher your match rate climbs. An event that leaves with twclid plus hashed email plus hashed phone will consistently match better than one carrying only a single field.
Setting up the X CAPI tag in the server container
On the implementation side, the most common path in 2026 remains the Stape Twitter Conversion API template, available for the GTM server container. Watch out for a real constraint: this version of the tag is designed to run on a server container hosted by Stape. If your sGTM runs elsewhere, check compatibility before committing, or move toward sending through the API directly. The official GTM Tag Gallery also offers solutions; compare the two based on your hosting.
Authentication uses OAuth 1.0a: you will need the Consumer Key, Consumer Secret, OAuth Token, and OAuth Token Secret, generated from your X developer account and tied to the right ad account. Once the tag is placed, map carefully: the event identifier (pixel_id or the equivalent identifier from your X pixel), the event name, the conversion_id for deduplication, the twclid, and the hashed identifiers. The checklist at the end of the article covers all of this point by point.
Verifying in X Ads Manager
Once the tag is live, do not trust the server returning a 200 status. A correct response code only means X accepted the request, not that the event was matched. Verification happens in the X Ads interface, in the Events Manager section, where you track event reception through the CAPI.
Two things to check first. First, that the web and server events for a single purchase appear deduplicated rather than counted twice: if your conversion volume doubles after enabling the CAPI, your conversion_id is not being shared correctly. Second, the match rate: X does not display a single score branded like Meta’s Event Match Quality, but you do have coverage and matching quality indicators that tell you how much of your events are properly paired to users. A low rate almost always points to a poorly captured twclid or missing identifiers.
Final checklist
Before you consider your X CAPI setup finished, run through this list:
- Both the client-side X pixel and the server-side CAPI tag send the same event.
- A unique
conversion_idis generated once and shared identically between the pixel and the server. - The
twclidis captured on the first page, stored in a durable first-party cookie, then sent in every CAPI conversion. - Each event carries at least one strong identifier (
twclid, hashed email, or hashed phone), ideally several combined. - SHA-256 hashing is done server-side, with a normalized email and a phone number in E.164 format.
- OAuth 1.0a authentication is correctly filled in and points to the right ad account.
- In X Ads Events Manager, events arrive, conversions are not double counted, and the match rate is satisfactory.
Installing the tag is never the point: clean deduplication and rigorous twclid capture are what separate an X tracking setup that inflates your numbers from one that actually feeds the algorithm. Fix those two, and your X signal finally reaches the level of the rest of your CAPI stack.