Conversions API (CAPI)
The Conversions API is Meta's method for sending conversion events directly from a business's server to Meta, as a supplement or alternative to the browser-based Meta Pixel, intended to capture events the browser alone would miss.
Why it matters
The pixel alone now misses a substantial share of conversions, due to browser restrictions, ad blockers and privacy settings. Since Meta's optimisation learns from the events it receives, missing events do not just under-report performance - they actively make the algorithm worse at finding buyers.
What people get wrong
That sending events through the API means they are being counted. A CAPI event that arrives without enough matching information - no hashed email, no phone, no click id - often cannot be attributed to a person who saw the ad, so it is received and then effectively discarded. The setup reports success at every step: events show as received in Events Manager, the integration reads green, and the conversions still do not appear where you expect them. Check the event match quality score, not whether events are arriving.
How it actually works
When a conversion happens - a purchase, a lead form submission - the business's own server sends that event directly to Meta's servers, bypassing the visitor's browser entirely. This is different from the Meta Pixel, which relies on code running in the browser to detect the event and report it.
Because the event comes from a server rather than a browser, Meta needs a different way to tie it to a specific person who saw or clicked an ad. It does this through matching: the event is sent along with hashed customer data such as email address, phone number, or a click identifier captured earlier in the visit. Meta compares that data against its own user records to decide whose ad exposure the conversion should be credited to.
The quality of that match, not the fact that the event arrived, determines whether the conversion actually gets attributed and used for optimisation. A perfectly delivered event with poor matching data is functionally the same as an event that was never sent, from the algorithm's perspective.
What goes wrong with it in real accounts
The most common failure is sending events with thin matching parameters - an event ID and nothing else, or an unhashed email that Meta cannot use. The event shows up in Events Manager as received, the integration looks healthy, and the account owner assumes the tracking gap that CAPI was meant to close has been closed. The event match quality score, a separate metric inside Events Manager, is the only place this actually shows up, and almost nobody checks it.
The second is duplicate counting when CAPI and the Pixel both report the same event without a shared event ID linking them. Meta is supposed to deduplicate matching events automatically, but that only works if both send the same identifier for the same customer action. Without it, every conversion is counted from both sources, inflating totals in a way that looks like a performance improvement right after CAPI is turned on.
The third is setting it up once and never revisiting it. CAPI implementations often depend on server-side code that references specific fields in a checkout or booking system; when that system is updated or migrated, the CAPI integration can silently stop sending the fields it needs, and the account reverts to Pixel-only performance without anyone changing a setting on the Meta side.
How it relates to the other terms
CAPI is a specific application of the broader idea behind server-side tagging: moving measurement off the browser and onto infrastructure the advertiser controls, though CAPI is Meta-specific rather than a general architecture.
It is almost always run alongside the Meta Pixel rather than replacing it, precisely because the two catch different events and deduplication between them is what makes the combined picture more complete than either alone.
Like every other measurement layer in this glossary, CAPI is downstream of conversion tracking fundamentals - if the event being sent was never a meaningful conversion in the first place, delivering it more reliably to Meta's servers does not make it one.
Frequently asked
Do I still need the Meta Pixel if I set up the Conversions API?
Yes, in almost all cases. CAPI and the Pixel are designed to work together, each catching events the other might miss, with Meta deduplicating overlapping events using a shared event ID. Removing the Pixel entirely usually reduces total tracked events rather than cleaning anything up.
Why do CAPI events show as received but not improve ad performance?
Received only means the event reached Meta's servers. If the matching data attached to it - hashed email, phone, or click ID - is too thin, Meta cannot confidently tie the event to a person who saw an ad, so it is not used for attribution or optimisation even though it was successfully delivered.
How do I check if my Conversions API setup is actually helping?
Open Events Manager and look at the event match quality score for the events coming through CAPI, not just whether the event count looks healthy. A low match score means the events are arriving but not being credited, which defeats the purpose of the integration.