CONNECTIONS / Shopify / Shopify to X CAPI
Shopify sales, still counted on X.
X remains part of the media mix for reach and response, and Signals keeps it measured the same way as every other channel: storefront checkout events, delivered server-side, deduped against whatever Pixel is already installed.
- ● shopify → x.capi :: live
- > event Checkout completed value=98.00 AED
- hash sha256(email) dedupe=pixel+server
- route x.capi match 55%
- ✓ delivered · event accepted
WHAT THIS ENABLES
Shopify to X Conversions API
Shopify to X Conversions API delivers checkout and purchase events from the storefront server-side to X, deduped against the X Pixel and enriched with hashed identifiers, so reach and response campaigns on X still get credited to the resulting sale.
- Checkout events reaching X even where the browser Pixel is blocked or dropped.
- Server-side parity with every other paid channel in the account, X included.
- Hashed identifiers attached to each event for better matching than the Pixel manages alone.
WHAT FLOWS WHERE
Shopify to X CAPI, mapped.
Once a Shopify checkout completes, Signals hashes the event and delivers it to X's Conversions API under the identifier the Pixel already carries, leaving X with a single record of the purchase.
Once a Shopify checkout completes, Signals hashes the event and delivers it to X's Conversions API under the identifier the Pixel already carries, leaving X with a single record of the purchase.
Built for the teams that own the number.
Teams that want the same server-side coverage on X as on every other platform they run.
From kickoff to verified events.
-
Install
Checkout and order webhooks enabled via app-scoped access, alongside the Web Pixel extension.
-
Map
Storefront events matched to X's conversion taxonomy, hashed identifiers attached at each step.
-
Deliver
Server-side delivery to X's Conversions API, deduped against the Pixel and verified in X Ads Manager.
What ships with this use case.
Deduped Pixel-plus-server coverage on the checkout events that matter.
Hashed identifier support for stronger matching than browser tracking alone provides.
Server-side delivery resilient to the same browser loss every pixel eventually hits.
What X CAPI actually receives.
- ● signals :: event payload
- > POST /conversion source=shopify.checkout
- conversion_time 1784519700000
- identifiers [{ hashed_email: "9c04ef…" }]
- conversion_value 98.00 · conversion_currency AED
- ✓ accepted · match=true
Adjacent moves on the same stack.
from Shopify
Shopify to every ad platform
Shopify to every ad platform is a single install that maps Shopify's order and checkout…
Learn morefrom Shopify
Shopify to Meta Click-to-Message
Shopify to Meta Click-to-Message Conversions ties a Shopify order back to the…
Learn more
same use case
BigCommerce to X CAPI
X Conversions API for BigCommerce: Signals reports online sales to X server-side so…
Learn moregeneric
X CAPI
Datahash implements X (Twitter) Conversions API with dedupe against the X Pixel and hashed…
Learn moreAsked on almost every call.
Do we keep the X Pixel that Shopify's native channel installed?
Yes. The Pixel and Conversions API events share an identifier, so X discards the duplicate rather than counting the checkout twice, and overall coverage improves from whichever signal arrives first. The Pixel still contributes browser-side events like page view that the server-side feed does not duplicate, so removing it would only reduce visibility rather than simplify anything.
How long does setup take on a storefront that already runs server-side CAPI for other platforms?
Typically a working session, since the checkout webhook and hashing pipeline already exist for other platforms and X becomes a matter of adding a destination and mapping its event taxonomy. There is no new webhook to install or hashing logic to rebuild, so most of the session goes toward confirming the mapping and verifying delivery in X Ads Manager.
NEXT STEP