Data & Tracking
Meta Conversions API: how to set up CAPI correctly alongside your Pixel
Copy for AI
The Meta Conversions API (CAPI) is a server-to-server connection that sends conversions such as a lead, a demo request or a purchase straight from your server or CRM to Meta. You set it up alongside the Meta Pixel, give each event the same ID in browser and server so Meta filters out duplicates, and test the result in Events Manager. That way Meta Ads learns from more and better conversion data than the browser alone passes on.
This guide is about the server side. If you first want to understand what the Pixel itself measures and which events exist, read our explanation of the Meta Pixel. This article starts where that one stops: how you choose, set up, deduplicate and check CAPI.
What exactly does the Meta Conversions API do?
According to Meta’s documentation, the Conversions API creates a connection between an advertiser’s marketing data, from the server, website platform, app or CRM, and the Meta systems that optimise targeting and delivery. Server events are used for measurement, reporting and optimisation, just like Pixel events.
The difference is the route. The Pixel runs in your visitor’s browser. That is where ad blockers, Safari’s tracking restrictions and scripts that fail to load come into play. CAPI starts on your side: your own server, your server-side tagging container or your CRM. That has three consequences that matter for B2B:
- Fewer missed leads. A form the browser does not pass on can still be reported by your server.
- Conversions that happen outside the website. A lead that becomes a qualified opportunity in your CRM three weeks later can be sent back as an event.
- Control over what you share. You decide which fields leave, hashed and all.
Which setup do you choose: partner, Gateway or server-side GTM?
Meta names three ways to connect CAPI: a partner integration, the Conversions API Gateway and a direct integration. In practice we see four variants at Belgian and Dutch companies.
| Setup | How it works | Fits | Watch out |
|---|---|---|---|
| Partner integration | Your CMS or shop (Shopify, WooCommerce plugin) sends events itself | Web shops on a standard platform | Little control over event names and deduplication |
| Conversions API Gateway | A Meta-managed server in your own cloud environment | Teams without their own tagging server | Meta only, no other platforms |
| Server-side Google Tag Manager | Your GTM server container sends events to Meta, LinkedIn, Google Ads | B2B with several ad channels | Needs hosting and a clean data layer |
| Direct integration from your CRM | Your CRM or backend calls the API | Offline and late conversions (SQL, deal) | Development work and maintenance |
For most B2B companies that also advertise on Google Ads and LinkedIn, server-side GTM is the logical foundation. You build one server-side layer and feed every platform from it. How that layer works is covered in our guide to server-side tracking.
If you have late conversions (a lead only gets qualified after a sales call), the CRM route comes into play. Mind the time limit: Meta’s parameter documentation states that event_time can be up to 7 days in the past. A deal that closes after six weeks can therefore no longer be sent as a website event.
How do you set up the Meta Conversions API, step by step?
This is the order we follow on every setup.
- Map your conversions. Which events really count? For B2B that is usually Lead (form), Schedule or a custom event for a booked demo, and possibly CompleteRegistration for a webinar. A page view is not a conversion.
- Make sure you have a data layer. Every form pushes an event with the same name and a unique event ID into the data layer. Without that ID Meta cannot deduplicate. How to measure forms reliably without a thank-you page is in our guide to form conversions without a thank-you page.
- Send the same event through the Pixel. The Pixel tag gets the event ID as eventID.
- Send the same event through the server. In your server-side container or integration the event goes to CAPI with event_name, event_time, event_id, action_source website, event_source_url and the customer data.
- Add customer data. A hashed email address (em), phone number (ph), the fbp and fbc values, and the visitor’s IP address and user agent. Meta requires client_user_agent for website events and asks you to hash contact details with SHA-256, while fbp, fbc, IP and user agent are not hashed, according to the documentation on customer information parameters.
- Respect consent. The server-side tag only fires if the visitor consented to marketing. More on that further down.
- Test and check. Use the test event code in Events Manager before you go live, then monitor deduplication and match quality.
How does deduplication between Pixel and CAPI work?
If you send the same event through browser and server, Meta receives it twice. Deduplication makes sure it only counts once. The rules are in Meta’s deduplication guide:
- the Pixel’s eventID must equal the CAPI event_id;
- the Pixel’s event name must equal event_name in CAPI;
- events are only deduplicated if they arrive within 48 hours of the first event with that ID;
- Meta generally keeps the event that arrived first.
You create the ID in the browser at the moment the form is submitted, and pass it through the data layer to both the Pixel tag and the server-side tag. A timestamp on its own is not a good ID: two leads in the same second then get the same number.
Meta also describes an alternative method using event_name plus fbp or external_id. It works, but it is less predictable. We always use an explicit event ID.
Which CAPI mistakes do we see most often?
In the accounts we review, the same problems keep coming back:
- Double counting. Pixel and CAPI send the same event without a shared ID. The number of leads in Ads Manager doubles, the cost per lead halves on paper, and the algorithm learns from a distorted picture.
- Two sources for the same event. The Shopify or WordPress plugin sends CAPI events and your server-side container does too. One source per event, not two.
- No customer data. CAPI events without email, fbp or fbc are hard for Meta to tie to a person. They then barely count towards optimisation.
- Unhashed or wrongly hashed fields. Hashing an email address with capitals or spaces gives a different hash. Normalise first (lower case, spaces removed), then hash.
- Every form click as Lead. Newsletter sign-ups and job applications then come in as leads too. Meta then optimises for the cheapest, not the best. This closely resembles what we describe in cleaning up false conversions.
- Bypassing consent. “It is server-side, so the cookie banner does not count” is a misunderstanding. More on that below.
How do you test whether the Conversions API works?
Check in this order:
- Test Events in Events Manager. Enter your test event code in your server-side tag, submit a test form and check that the event arrives through both browser and server.
- Deduplication. In your dataset overview you see per event whether browser and server events are being deduplicated. If you see two separate ones, the ID or the event name is wrong.
- Match quality. Events Manager shows a score per event for the quality of the customer data. If it is low, check whether email, fbp and fbc are being sent.
- GTM preview. In the preview of your web and server containers you see whether the event ID is the same in both tags.
- CRM comparison. Put the number of Meta leads per week next to the number of leads from Meta in your CRM. A big gap points to duplicates or missed events.
We do a full check of your measurement, including Google Ads and GA4, in a tracking audit. If you want to start yourself, use our conversion tracking audit checklist.
Can you use CAPI without cookie consent?
No, not for marketing. The Belgian Data Protection Authority states that no cookie or other tracker may be placed or read without prior information and consent, except what is strictly necessary. In the Netherlands, the Dutch Data Protection Authority (Autoriteit Persoonsgegevens) takes the same line. That the data runs through your server does not change the purpose: ad measurement and targeting. So make your server-side tag depend on the same consent as your Pixel.
What CAPI does solve: the losses that do not come from refusals, such as ad blockers, browser restrictions and scripts that load too late. How to set up your banner and Google signals properly is covered in our guide to Consent Mode v2 and in cookie banner rules in Belgium. This article is not legal advice: run your setup past your DPO or lawyer.
How do you send CRM data back to Meta?
For B2B the real gain is not the form, but what happens after it. A lead who never picks up the phone is as valuable to Meta as a lead who becomes a customer, unless you send the difference back.
- Store the fbc value (derived from the fbclid in the URL), the fbp cookie and a hashed email address with every lead in your CRM.
- Decide which CRM stage you send back, for example “qualified” or “demo held”.
- Send that stage as an event with action_source system_generated or website, within the window Meta allows.
- Optimise your campaigns on that deeper event once there is enough volume.
We use the same logic for Google Ads in importing offline conversions from your CRM. At Kaizo we built the Meta measurement on the same booked demo as Google Ads, so both channels optimise on the same event: read the Kaizo tracking case. And how one broken form listener silenced GA4, Google Ads, Meta and LinkedIn at once is told in the Suivo case.
When do you not (yet) need the Conversions API?
If you barely advertise on Meta, or your leads mainly come in through Lead Ads forms inside Facebook and Instagram, CAPI for website forms adds little. At very low volumes (a handful of leads a month), a correct Pixel with good event names and clean CRM records matters more than a server-side layer. Start there, and add CAPI once Meta becomes a real channel in your Meta Ads approach.
If you want CAPI set up together with your Google Ads, LinkedIn and GA4 measurement, our tracking specialist does it in one server-side setup, tailored and on request. Get in touch for a first check.
If you advertise on several platforms, also read our guides on LinkedIn Insight Tag, TikTok Pixel and Stape.
Frequently asked questions
What is the difference between the Meta Pixel and the Conversions API?
The Pixel measures in the visitor’s browser, the Conversions API sends events from your server or CRM. Meta recommends using both and deduplicating them with a shared event ID.
Do I need server-side Google Tag Manager for CAPI?
No. A partner integration or the Conversions API Gateway can also work. Server-side GTM is mainly interesting if, besides Meta, you also want to feed Google Ads, LinkedIn or TikTok server-side from one container.
Why do I see duplicate conversions after installing CAPI?
Usually the shared event ID is missing, the event name differs between Pixel and server, or two integrations (for example a plugin and your server container) send the same event.
Can I send offline conversions through the Conversions API?
Yes, as long as the event falls within the window Meta allows. For late B2B conversions, store fbc, fbp and a hashed email address with the lead in your CRM, so Meta can tie the conversion to the right person.
Does CAPI work when a visitor refuses cookies?
Technically the server can send events, but in Belgium and the Netherlands you may not do so for marketing without consent. CAPI mainly recovers losses from ad blockers and browser restrictions, not from refusals.
Free website scan
Enter your website and get an automatic scan within minutes, with concrete technical and SEO improvements. No sales pitch.
We only use your details for your scan. No spam, unsubscribe anytime.