Key takeaways
- The Meta Conversions API (CAPI) sends events server-side, so they do not depend on the browser loading a pixel.
- It is designed to run with the Meta Pixel, not instead of it, with deduplication keeping shared events from being counted twice.
- Customer identifiers are hashed with SHA-256 before they are sent, so Meta receives irreversible strings, not readable data.
- More complete event data improves Event Match Quality, attribution, and the signal that Meta's optimisation learns from.
- The same event ID on the pixel and the server event is what lets Meta discard the duplicate.
- CAPI recovers events that already happen; it cannot measure customers who never converted.
- KFC saw 5% additional purchases running the Meta Conversions API alongside the pixel, versus the pixel alone.
What is the Meta Conversions API?
The Meta Conversions API is Meta’s server-side channel for conversion events. The Meta Pixel measures actions in the browser, which is increasingly fragile: ad blockers, tracking-prevention settings, and cookie limits stop a share of pixel events from ever reaching Meta. The Conversions API sends the same events from your server instead, where those restrictions do not apply. Meta for Developers documents it as part of the Conversions API family that spans web, app, offline, and messaging. Running it with the pixel gives Meta two paths to the same event, so a purchase the browser drops still arrives from the server.
How does the Meta Conversions API work?
The Meta Conversions API works by building each conversion event on your server and posting it to Meta with the customer’s hashed identifiers attached. The steps run in order:
- A customer acts on your site or app: a view, an add-to-cart, a purchase.
- Your server builds the event with a name, a timestamp, the value, and a unique event ID.
- It attaches hashed identifiers, such as email and phone, plus the Meta click identifier where present.
- It posts the event to the Conversions API endpoint.
- Meta matches the event to a person and, if the pixel already sent it, deduplicates on the shared event ID.
Meta for Developers sets out the event structure and the deduplication rule, which is the piece that makes running the pixel and the server together safe.
How do you connect the Meta Pixel and the Conversions API?
Connecting the Meta Pixel and the Conversions API means sending the same events on both paths and telling Meta they are the same. You keep the pixel firing in the browser, add the server events, and give each shared event an identical event ID. Meta keeps one copy and discards the duplicate. Done correctly, you get the browser detail the pixel captures and the reliability the server provides, without inflating your numbers. Skipping deduplication double-counts, which flatters reporting and misleads the optimiser at once. Datahash sets up the Meta Conversions API for web events with deduplication configured from the start.
What can you automate with the Meta Conversions API?
The Meta Conversions API can carry any server-recorded outcome, not only website purchases, which is what makes it more than a pixel replacement. The events below are the common ones, and each can be sent from wherever it truly happens:
| Event | Where it happens | Why send it server-side |
|---|---|---|
| Purchase | Checkout or back-office | Survives browser blocking, carries true value |
| Lead | Form or CRM | Can be sent when the lead qualifies, not just submits |
| Subscribe | Billing system | Recorded where the charge actually clears |
For events that originate in a CRM rather than the site, the Meta Conversions API for CRM leads carries the funnel stage back to Meta.
What are the limits of the Meta Conversions API?
The Meta Conversions API improves how reliably events reach Meta; it does not create events that never happened. If a customer does not convert, there is nothing to send, and CAPI cannot manufacture demand a weak offer failed to create. Match quality still depends on the identifiers you hold, so events sent without an email, phone, or click ID match poorly. And running it without deduplication is worse than not running it at all, because double-counted conversions corrupt both your reporting and Meta’s optimisation. CAPI recovers and stabilises signal that already exists. It is not a growth tactic on its own.
What Datahash does about this
Datahash runs the Meta Conversions API as managed server-side infrastructure. It hashes the identifiers, sends the events, and configures deduplication against the pixel so numbers stay honest, and it does the same for sending app events to Meta, offline, and messaging on one first-party data layer. For teams that want the fastest start, the Meta CAPI gateway with one-click setup relays pixel events server-side without a build. Because the hashing happens before anything leaves your systems, the setup stays consistent with GDPR and DPDP. KFC recorded 5% additional purchases running the Conversions API alongside the pixel versus the pixel alone, and Starzplay saw an 11.7% increase in attributed free-trial subscribers, both because the server path recovered events the browser was dropping. Event Match Quality is visible per event, so you can see the recovery rather than assume it.