CONNECTIONS / Shopify / Shopify POS to Meta Offline CAPI
Shopify POS to Meta Offline CAPI, in production this week.
Every register transaction in Shopify POS becomes a hashed offline conversion at Meta, deduped against the online orders you already send.
- ● shopify → meta.offline_capi :: live
- > event POS order placed value=214.00 AED
- hash sha256(email,phone) dedupe=online+pos
- route meta.offline_capi deliver
- ✓ delivered · match 81%
WHAT THIS ENABLES
Shopify POS to Meta Offline CAPI
Shopify POS to Meta Offline CAPI captures in-store transactions the moment a Shopify POS terminal rings them up, hashes and dedupes them against existing online orders, and delivers offline conversions to Meta so campaigns credit revenue that closed at the counter as well as online.
- Register transactions reaching Meta within moments of the sale.
- Unified measurement across the counter and the online checkout.
- Event IDs guarding against double counting between POS and web.
- Refunded POS orders reconciled against the original event, so a returned item doesn't leave inflated revenue behind.
The click, the conversion, and the credit.
The conversion happens off Meta, away from any pixel. Here is how Shopify closes the loop.
Built for the teams that own the number.
Brick-and-click brands proving store revenue to their Meta campaigns.
Fashion and footwear merchants with high in-store return rates who need refund-adjusted reporting.
From kickoff to verified events.
-
Connect
One app install covering every POS location, permissions scoped and revocable.
-
Map
POS webhooks translated into Meta's offline event format with hashed keys.
-
Deliver
Continuous delivery to the offline endpoint, deduped and match-reported.
What changes when the CSV goes away.
| Capability | Manual CSV upload | Datahash |
|---|---|---|
| Reporting | Offline sales sit in a separate export, reconciled by hand. | Revenue counted in the same Offline CAPI reporting as web conversions. |
| Deduplication | A re-uploaded file risks counting the same conversion twice. | Deduped delivery, so a resent record never counts as a second conversion. |
| Match visibility | Match quality is a guess until the numbers look off. | Match rate reported per upload, tied to the source event set that produced it. |
| Effort and latency | An analyst exports and uploads on a manual cadence. | Server-side and automatic the moment Shopify records the event. |
What Offline CAPI actually receives.
- ● signals :: event payload
- > POST /offline_conversions source=shopify.pos_order
- event_name "Purchase" · event_time 2026-07-04T17:40:00
- value 214.00 · currency AED
- em sha256 "d02c19…" · ph sha256 "66be4a…" · external_id "pos-30281"
- ✓ accepted match=81%
Adjacent moves on the same stack.
from Shopify
Shopify to Google OCI
Shopify to Google Offline Conversion Import carries the GCLID captured on a storefront…
Learn morefrom Shopify
Shopify to Google Store Sales
Shopify to Google Store Sales hashes customer and order data from both the online…
Learn more
same use case
ActiveCampaign to Meta Offline CAPI
ActiveCampaign to Meta Offline CAPI: Signals reads your ActiveCampaign contacts and deal…
Learn moregeneric
Meta Offline CAPI
Datahash ingests offline transactions from your POS, CRM, or warehouse and routes them to…
Learn moreAsked on almost every call.
Does this double-count with online orders?
No. Every Shopify POS order carries an event ID that Signals also checks against the matching online order stream before delivery. When the same sale shows up through both the point-of-sale terminal and an online channel, Meta keeps only the first copy it receives, so a store cannot end up crediting one purchase twice in reporting.
What identifiers does POS capture?
Email and phone are captured where the POS terminal collects them at checkout, such as during loyalty sign-up or a receipt request. Coverage is often partial compared to online orders, since not every till transaction gathers contact details, but even a phone number alone still moves match rates meaningfully once it reaches Meta hashed.
What happens to a Meta offline event when the POS order is later refunded?
Signals reconciles the refund against the original order record and excludes it from the next delivered batch, rather than leaving a phantom sale sitting in Meta's reporting. High-return categories like fashion and footwear see the biggest benefit from this, since refund volume there is high enough to skew match reporting if left unreconciled.
NEXT STEP