Meta’s Conversions API (CAPI) is a server-side endpoint — but most Shopify CAPI implementations still depend on the browser to capture the event first. When an ad blocker intercepts the Meta Pixel or the client-side relay, the event never reaches your server to forward. The fix is capturing purchases from Shopify’s own infrastructure (webhooks) instead of the visitor’s browser.
Why does a server-side API still get blocked?
CAPI itself cannot be blocked — it’s a server-to-server call. The problem is upstream: the standard Shopify setup fires the Meta Pixel in the browser, and a gateway (the Shopify Meta app or a tag manager) translates that browser event into a CAPI call. Block the pixel, and the trigger never fires. The server-side leg exists, but it’s waiting on a browser event that never arrives.
What exactly do ad blockers intercept?
Blockers filter requests by domain pattern (facebook.net, connect.facebook.com) and by script behavior. Modern blockers also catch first-party proxy setups that forward to Meta’s domains. What they cannot intercept is traffic between two servers — Shopify’s webhook infrastructure posting an order to your relay, and your relay posting to Meta’s graph API. Neither request touches the visitor’s device.
How do you make CAPI delivery browser-independent?
Capture the purchase from Shopify’s orders/paid webhook — the order object arrives server-side regardless of what the visitor’s browser did. Transform it into Meta’s Purchase event schema, attach the fbc click ID from your first-party cookie or attribution store, hash customer parameters, and post to the Conversions API with an event_id for dedup. PixelRelay automates this entire pipeline: webhook capture, dedup against any surviving browser pixel, and delivery with live “X of Y orders delivered” counts you can check against Shopify admin.
How do you verify the fix works?
Compare Meta’s reported purchases against Shopify admin order counts over a 7-day window. Before the fix, stores with high blocker traffic typically see 20–40% gaps. After webhook-based capture, the gap should narrow to near-zero for paid orders — verify with your own numbers rather than trusting any vendor’s published percentage.
FAQ
Does this violate Meta’s policies? No. The Conversions API is Meta’s official server-side product; sending from your own infrastructure is the intended usage.
Do I still need the browser pixel? Keeping it gives you richer behavioral events (ViewContent, AddToCart) on unblocked sessions. Just deduplicate purchases — PixelRelay does this automatically via event_id matching.
What about iOS 14+ attribution windows? Server-side delivery doesn’t change Meta’s attribution modeling, but it does ensure the purchase event actually arrives for Meta to attribute — the event volume problem is separate from the attribution window problem.
