How to Set Up X (Twitter) Ads Conversions API Tracking on Magento 2

TL;DR

The addon's own screen has ten fields. The X half has an order to it, and doing it out of order costs you a set of credentials. You need Ads API access approved on a developer app, access tokens generated after that approval by a user with the right role, and event IDs that already exist on the pixel side. With those in place the addon sends up to eight events with the same deduplication key the pixel uses, and on X that key is what stops a purchase from counting twice.

Key Takeaways

• Request Ads API access through X's Ads API Access Form before anything else; X offers a "Conversion Only" access level covering its Mobile and Web Conversion endpoints [4].
• Generate the access token and secret after approval. X says user access tokens must be regenerated once the app is approved, and regenerating invalidates the old ones [4].
• The token user needs AD_MANAGER or ACCOUNT_ADMIN access, and X recommends a company handle, since credentials tied to a developer's own handle cannot be transferred [3].
• Event IDs are set in the GA4 PRO X pixel section, not in the addon. Without them, server-side data is not associated with your X events [1].
• X deduplicates Page View events within 30 minutes and does not deduplicate Purchase-type events by default; the conversion_id key is what lets the two copies count once [6].
• Verify in twitter-api.log, in the admin log view added in v1.15.11, and in X reporting, which X finalizes within 24-48 hours [1][6].

Get Ads API access before you open Magento

The addon guide is plain about where this setup starts: you "won't have access to these details unless X (Twitter) approves your application" [1]. The details are the OAuth values the addon asks for, and X's conversion documentation states the primary requirement as "having a Developer Account and Ads API Access" [3].

Access is requested per developer app, through the Ads API Access Form [4]. One of the levels on offer is "Conversion Only", which X describes as access to the Mobile and Web Conversion endpoints with read and write access [4], a description that matches what the addon does.

Then comes the step that decides whether you do the Magento half once or twice. X's getting-started guide: "After your app is approved for Ads API access, you will need to regenerate any user access tokens" [4]. Keys and tokens display only once, and regenerating them invalidates the old ones, so every integration using them needs the new values [4]. A token pair generated while your application was still pending is a pair you will throw away.

The tokens also have to belong to the right person: a user with AD_MANAGER or ACCOUNT_ADMIN access level, ideally on a company handle; the handle owning the app gets its tokens from the Developer Console, and any other handle goes through 3-legged OAuth [3]. There are four values because Ads API requests are signed with OAuth 1.0a, using the app's key and secret plus a user's access token and secret [5].

Here is where each Magento field comes from:

The screen itself is Admin → WeltPixel → Google Analytics 4 Ecommerce PRO → X (Twitter) Ads Tracking Settings [1]. The addon needs a working client-side X pixel, because enabling server-side tracking uses the X tracking code configured in the pixel section [1], on top of the base configuration in the complete server-side setup guide. Our March 2025 launch overview of the addon did not cover the credential order above.

Where do the event IDs go?

One screen away from where you would look. The addon's Track Events field chooses what goes to X server-side, and its options are Purchase, Search, Add to Cart, Add to Wishlist, Initiate Checkout, Add Payment Info, View Category and View Product [1]. The IDs that tie those events to X live in the client-side pixel configuration, at Admin → WeltPixel → X (Twitter) Pixel Tracking → X (Twitter) Pixel Tracking Configuration, in Twitter Event IDs, where each GA4 tracking event needs its own unique ID from your X Ads account [2]. The addon guide states what happens if you skip it: "Otherwise, server-side data won't be associated with your created event in the X Ads Platform" [1].

X gives the reason the IDs have to be the pixel's: to deduplicate pixel and Conversion API events, "you need to use the existing event you created for Pixel" and pass the deduplication key in both [3]. If the event already exists for the pixel, X says to take the Event ID from that event [3].

The pixel section has its own Track Events setting covering the same eight event types, labeled the way X's pixel labels them [2]. The two lists are separate configurations.

What our guide does not settle is which X event type to create for each Magento event. X's help center lists its current types as Page view, Add to cart, Lead, Added payment info, Purchase and Custom [6], and neither document prescribes a pairing for Search, View Category or the rest. The requirement that does exist is one X event, and one ID, per Magento event you send [2].

If you set up the X pixel in 2025 and have not opened that section since, open it before you enable the addon. GA4 PRO v1.15.7, September 2, 2025, fixed a bug that removed the X pixel's event mapping when the extension was disabled and re-enabled, and the same release fixed 0 parameters being sent to X with the Purchase and Add Payment Info events [2]. Server events depend on that mapping, so an older build that was switched off and on once may have lost the link.

Does X deduplicate the pixel and server copies for you?

Partly, and the part it skips is the one carrying revenue. X's help center table is short: Page View events are deduplicated within 30 minutes, while "Other event types (Purchase, Lead, etc.)" do not dedupe [6]. What makes a browser copy and a server copy of the same purchase count once is conversion_id, which X defines as a "Unique identifier for the event that can be used for deduplication purposes" and strongly recommends when you run the pixel and the Conversions API together [6].

That is the lens for the addon's Send enabled events via the frontend X (Twitter) Pixel as well setting [1], which is off by default. The guide's own description of it is cautious about duplication. X's table is specific: without a shared key, a purchase sent from both the browser and the server is two purchases. The pixel and the addon send the same deduplication key for the same event. That shared key is the condition X sets for counting the pair once [6]. X states no time window for that key.

What X needs to match a conversion

X sets a floor. Every event needs at least one identifier such as the Click ID (twclid), an email address or a phone number, and if you rely on IP address or user agent, a second identifier has to come with it [3]. Email and phone go SHA-256 hashed without salt, phone in E.164 format, and X recommends always including the Click ID [3].

The 1.16.1 change is the one to understand. Our change log says it "works to increase match quality scores" for returning customers [1]. Read against X's floor, that is the case with no ad click behind it: a later View Product or Add to Cart that carries no twclid can still carry hashed contact data from an earlier purchase.

A store behind Cloudflare on a build older than v1.14.19 sent X the CDN's address as the visitor's [1]. Upgrading corrects what is sent from then on, and it does nothing for events already delivered.

How do you confirm events are reaching X?

Three surfaces, in the order they can answer. Enable File Log writes the pushed event data to twitter-api.log in Magento's var/log directory, one line per event since v1.15.7 [1]. Since v1.15.11, November 25, 2025, an admin interface shows the same payloads and event logs without server access [1]. Then X itself, whose reporting is finalized within 24-48 hours of when impressions are served [6].

1. Switch on Enable File Log and place a test order.
2. Find the Purchase line in twitter-api.log or the admin log view and check that it carries a value, a currency and at least one identifier from the table above.
3. If the test order never appears and you placed it from a staff account, look at Track Only Specific Customer Groups first; since v1.15.3 the addon can send selected customer groups only [1].
4. Judge the count in X after the 24-48 hour window, when X finalizes it [6].

The wider chain, DebugView and the order grid included, is in our guide to verifying GA4 events on Magento 2.

What the addon does not do

It sends to one X account. Our Pinterest and Microsoft Ads addons document sending to more than one advertiser or endpoint. The X guide documents no such option [1], so a store running two X ad accounts serves one of them through this path.

Conversions for somebody else's order are refused since v1.17.5, September 16, 2026: the public server-side tracking endpoint only sends events for the current session's own order or cart, so a remote caller can no longer force or duplicate an X conversion for another order [1].

Consent posture stays your decision. X's own documentation says your server code may need logic to "filter out conversion events of users that have exercised relevant privacy choices" [3]. Since v1.17.4, September 1, 2026, with Require Visitor Consent for Server-Side Events enabled in the GA4 configuration, the X addon's server-side events are gated on the shopper's advertising consent and order events are judged on the consent stored with the order; the setting is off by default, and our guide to making server-side events respect consent covers switching it on [1][2].

The same release added server-side bot filtering on the same editable pattern list as the GA4 Measurement Protocol, so self-identifying crawlers are no longer sent to X, and order events are always sent [1]. The list itself is covered in keeping bot traffic out of GA4 and your CAPI reports.

FAQ

Do I need the X pixel set up before the addon?

Yes. The addon's requirements include the client-side X pixel configured in GA4 PRO, and server-side tracking uses the tracking code from that section [1]. The event IDs live there too [2].

Does the addon send registration or sign-up events?

No. Track Events offers eight events, from Purchase to View Product, and registration is not among them [1].

Is the addon available for the GA4 STANDARD edition?

No. It requires GA4 PRO [1]. How the two editions differ is in our STANDARD vs PRO comparison.

Which Magento versions does it support?

Magento 2.3.x through 2.4.9, all editions, with support for multiple store views [1]. Installation is Composer-only since v1.16.0 [1].

The X (Twitter) Ads Conversions API addon sends Magento's eight selectable events to X with the same deduplication key as the pixel, currently v1.17.5, released September 16, 2026. It runs on the PRO edition of the Magento 2 Google Analytics 4 extension, which also carries the client-side X pixel whose event IDs the addon depends on.

Sources

1. WeltPixel X (Twitter) Ads Server-Side Addon User Guide and Change Log, v1.17.5, September 16, 2026, retrieved September 28, 2026, https://docs.weltpixel.com/TwitterAddon/User-Guide-WeltPixel-Twitter-Addon.html
2. WeltPixel Google Analytics 4 User Guide and Change Log, v1.17.5, September 16, 2026, retrieved September 28, 2026, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
3. Web conversions, X Ads API documentation, retrieved September 28, 2026, https://docs.x.com/x-ads-api/measurement/web-conversions
4. Step-by-step guide, X Ads API getting started documentation, retrieved September 28, 2026, https://docs.x.com/x-ads-api/getting-started/step-by-step-guide
5. Making authenticated requests, X Ads API documentation, retrieved September 28, 2026, https://docs.x.com/x-ads-api/fundamentals/making-authenticated-requests
6. Conversion tracking for websites, X Business Help Center, retrieved September 28, 2026, https://business.x.com/en/help/campaign-measurement-and-analytics/conversion-tracking-for-websites