The Conversions API, usually shortened to CAPI, is Meta’s way of letting your website server, e-commerce platform or CRM send conversion events, such as purchases and leads, directly to Meta instead of relying only on the Meta pixel running in the visitor’s browser. Most setups now use both together.
How the Conversions API works
The pixel is a piece of JavaScript that fires in the browser when someone views a page or completes a form. Browser tracking loses events for many reasons: ad blockers, privacy features in Safari and Firefox, a visitor closing the page before the script loads, or a person declining cookies. CAPI sends the same events from your server, which is not affected by most of those browser issues.
Each event carries an event name (Purchase, Lead and so on), a timestamp, the page URL and customer information such as an email address or phone number. Personal identifiers like these are hashed with SHA-256 before sending, so Meta can match the event to an account without receiving the raw value. How well that matching works is shown as event match quality in Events Manager.
Because the pixel and the server often report the same purchase, both should send a shared event ID. Meta then uses deduplication to count the sale once. Without that ID, conversions can be double counted and every report looks better than reality.
Ways to set it up
- Platform integrations. Shopify, WooCommerce and several other platforms offer built-in or plugin connections.
- Server-side tagging. A server-side Google Tag Manager container can forward events to Meta alongside other platforms.
- Direct integration. A developer calls the API from your own code, which suits custom sites and sending offline events such as a sale closed by phone.
- Meta’s Conversions API Gateway. At the time of writing (October 2026), a low-code option that Meta provides to run in your own cloud account or through a hosting partner.
Why it matters
Meta’s delivery decisions rely on the events you send back. If a third of your sales never reach Meta, the system optimises on a partial picture and your reported cost per result looks worse than it is. CAPI usually closes part of that gap, and it lets you send events that never happen in a browser at all, such as a lead that became a paying customer two weeks later.
For UK businesses there is a legal point that is often missed. Sending data from the server does not remove the need for consent or a lawful basis. PECR still governs cookies and similar technologies such as the pixel, and UK GDPR still governs sharing personal data, hashed or not, with Meta for advertising. If someone declines marketing cookies on your site, the server should respect that choice and not send their events anyway. Moving where the data is sent from does not change which rules apply to it.
Common mistakes
- No deduplication. Pixel and server both report a purchase and it is counted twice.
- Ignoring consent signals. The server sends everything regardless of what the visitor chose in your cookie banner.
- Sending too little customer data. Events without email, phone or click ID match poorly, so the extra data adds little.
- Not updating the privacy notice. Visitors should be told their data is shared with Meta for advertising.
How to act on it
Open Events Manager and check which events arrive from the browser, which from the server, and the match quality for each. If you see no server events, start with your platform’s integration. Then pass the consent state from your consent tool to the server so events are only sent where consent exists, and record the setup in your privacy notice.
Test with a real purchase or form submission and confirm it appears once, not twice. I set this up as part of my Facebook ads management service, because accurate events matter more to a Meta account than almost any setting in Ads Manager.