What Meta CAPI does
The Meta Conversions API sends the same conversion events your Pixel already tracks - PageView, Lead, Purchase, CompleteRegistration - but from your own server instead of (or alongside) the visitor's browser. Meta receives the event, checks it against parameters you send (email, phone, external ID, hashed per Meta's spec), and uses it for both conversion reporting and audience/optimization signal, the same way it uses pixel events.
The point is not to replace the Pixel. It is to stop losing events the Pixel alone cannot reliably deliver anymore.
How delivery works
A CAPI call is a server-side HTTP POST to Meta's Graph API conversions endpoint, carrying the event name, event time, event source URL, one or more pieces of hashed customer data for matching, and (critically) an event_id matching the corresponding Pixel event if one also fired for the same action.
Implementation paths, in order of how often we see them:
- Server-side GTM. If you already run a server-side Google Tag Manager container (see gtm.webclat.com), the Meta CAPI call becomes another tag in that container, reusing the event data already flowing through it. This is the path we recommend when one exists.
- Direct server integration. A backend call made directly from your application server or a lightweight middleware layer, for teams without a server-side tag manager.
- Platform-native (Shopify). Shopify's Meta and Instagram channel app includes a native CAPI toggle - fastest to turn on, least flexible for custom event definitions.
- WooCommerce. Either a CAPI-capable plugin or a custom implementation hooked into WooCommerce's order and cart events.
Deduplication with the Pixel
This is the step most implementations get wrong. If the Pixel and CAPI both send the same conversion without a shared event_id, Meta counts it twice - inflating your reported conversions rather than recovering lost ones. Correct dedupe means:
- Generating one event ID per real-world event (not per request), shared between the client-side Pixel call and the server-side CAPI call
- Sending both event name and event ID identically on both sides
- Verifying, per event, that Events Manager reports a single deduplicated conversion, not two
Consent handling
A CAPI event should be gated on the same consent state your Pixel already respects - if a visitor has not consented to tracking, the server-side event should not fire either. This is wired to your consent management platform (OneTrust implementation lives at ot.webclat.com) rather than left to fire unconditionally just because it bypasses the browser.
How to verify it worked
Confirm in Meta Events Manager, not from your own server logs:
- Open Events Manager -> your Pixel -> Overview, and check the "Event Match Quality" and deduplication columns for the event in question
- Send a test event using Meta's Test Events tool and confirm it shows a server source, not just browser
- Fire a real conversion (or a controlled test purchase) and confirm exactly one event appears, tagged as deduplicated between browser and server
- Check Event Match Quality score - a low score usually means missing or improperly hashed customer parameters, not a delivery failure
Troubleshooting incomplete pixel data
If Meta's reported conversions are consistently lower than your own backend order/lead count, the gap is almost always one of: ad-blocker/ITP loss on the Pixel side (which CAPI addresses directly), a broken or absent event ID (causing either double-counting or a CAPI event that never gets credited because it looks like a duplicate of nothing), or a consent gate that is blocking more traffic than intended. We diagnose which one it is before writing any code.