Meta Conversions API for PrestaShop: do you need it?

If you advertise on Meta and run a PrestaShop store, you have probably been told to "add the Conversions API" without a clear explanation of what it does or whether you actually need it. The honest answer is: most stores running paid social do need it now, but not because it is fashionable. It exists to recover the conversions the browser-based pixel can no longer see.

This guide explains what Meta CAPI is, who genuinely benefits, how the pixel and the Conversions API work together rather than competing, and the technical details — deduplication, server-side tokens, and identity matching — that separate a setup that helps from one that quietly double-counts your sales.

What the Conversions API actually is

The Meta pixel is a piece of JavaScript that runs in the shopper's browser and reports actions like purchase and add-to-cart back to Meta. It has been the backbone of Facebook and Instagram advertising for years. The problem is that it lives entirely in the browser, which is exactly where ad-blockers, privacy extensions, and Apple's App Tracking Transparency now intercept it.

The Conversions API (CAPI) is the server-side counterpart. Instead of relying on the browser, your server sends the same conversion events directly to Meta over a server-to-server connection. Because nothing in the customer's browser can cancel that request, events that the pixel would have lost still arrive.

Think of CAPI not as a replacement for the pixel but as a second, more reliable delivery path for the same information. The best results come from running both, which we explain in detail under server-side vs client-side.

Who actually needs it

Not every store needs to rush. If you spend nothing on Meta ads, CAPI does little for you — there is no campaign optimisation to improve and no attribution to recover. Your effort is better spent elsewhere.

But if you run any meaningful Meta advertising, the calculus flips quickly. The more your audience skews toward iOS, Safari, and privacy-conscious users, the more the pixel under-reports — often losing 30-50% of conversions. Every lost purchase event is a sale Meta's algorithm never learns from, which means worse audience building, weaker optimisation, and a return on ad spend that looks artificially poor.

Stores with a healthy ad budget, a mobile-heavy customer base, or campaigns that depend on accurate conversion values (such as value-based bidding) get the clearest payback from CAPI. If that describes you, it has stopped being optional.

Pixel and CAPI together, not instead

A common misconception is that CAPI replaces the pixel. It does not, and it should not. The pixel still captures rich browser-side context — the _fbc and _fbp cookies, browser parameters, and on-page behaviour — that improves matching. CAPI provides reliability and server-side data the browser never had.

Run both and you get the best of each: the pixel's behavioural richness plus the Conversions API's resistance to blocking and ITP. Meta is explicit that the recommended setup is redundant, with the same event sent from both the browser and the server.

The word "redundant" is the catch. If you naively send the same purchase from both the pixel and CAPI, Meta could count it twice. That is where deduplication becomes essential, and getting it right is the single most important part of a hybrid setup.

Deduplication via a shared event_id

Deduplication is how Meta recognises that a browser event and a server event describe the same sale, so it counts them once. The mechanism is a shared event_id: when the pixel and CAPI both fire for one purchase, they send the identical event_id, and Meta collapses the pair into a single conversion.

The trap is using a random identifier. If the pixel generates one random event_id and the server generates another, Meta sees two different IDs and counts two purchases. The fix is a deterministic identity: derive the event_id from the PrestaShop order reference, so both paths compute the same value independently, and a reloaded confirmation page cannot inflate your numbers.

This is exactly how PrestaSignal handles it — one deterministic event_id per order, reused across the pixel, CAPI, and even your GA4 tracking, so nothing double-counts anywhere. See our glossary for the related terms.

The token stays on the server

CAPI authenticates with a Conversions API access token. This token is powerful — it can send conversion data to your Meta account — so it must never appear in the browser, in page source, or in any client-side script. If it leaks, anyone can pollute your conversion data.

This is one of the strongest arguments for a proper server-side setup rather than a browser-based shortcut. PrestaSignal keeps the CAPI token inside the self-hosted sGTM container, server-side only, where the browser never sees it. The Meta tag in the container holds the token; the customer's device never does.

Keeping the token server-side is not just good security hygiene — it is the only correct way to run CAPI. Any approach that exposes it in the browser has misunderstood what the Conversions API is for.

external_id and better matching

Reliable delivery is only half the value of CAPI. The other half is matching — Meta's ability to connect a conversion to a person who saw your ad. The more high-quality identifiers you send, the higher your event match quality, and the better Meta can attribute and optimise.

Server-side, you can send hashed customer data — email, phone, name — and an external_id, which is typically a SHA-256 hash of the customer ID. The external_id gives Meta a stable, cross-device anchor: the same customer on their phone and laptop resolves to one identity, improving both attribution and audience building.

All of this personal data is normalised and hashed with SHA-256 before it leaves your store, so Meta receives irreversible fingerprints rather than readable details. To see how much Meta is currently under-reporting on your account, book a teardown and we will measure it against your real PrestaShop orders.