How Does the Facebook Conversions API Work?
The Facebook Pixel sends conversion data from a visitor’s browser. The Conversions API sends it from your server. Here’s what’s actually happening, step by step.
Emmett Cooke
Founder, PixelFlow.so
Last updated 17 June 2026
8 min read
You Send Facebook Data via 2 Paths
The Facebook Pixel and the Conversions API are two different ways of sending data to Meta.
The Pixel runs in the customers browser when they open your website and triggers when they do something like load a page or click complete a purchase. It packages up the event, attaches whatever information it can see (cookies, IP address etc.), and sends it to Facebook.
The Conversions API does the same job but it goes from your website to a server and then to Meta (nothing via browser)
The reason why both exist is that the Facebook pixel is usually blocked by users and can’t collect much information. The server channel is not.
Facebook Combines Both Events into One
When the Pixel and the Conversions API both send the same event, Facebook needs to:
Know they’re the same event sent
Combine the data from both
To do this, you use the same identifier (“event_id”) so Facebook knows they’re the same event, just received by both browser & server and deduplicate (won’t count them twice)
Next, Facebook combines the data from both events into one, taking the best information from both and then matches the event to a specific real person in its records.
For events like PageViews, you’re not going to have much data. But for events like Purchases, Leads etc. you should have plenty of information like name, email, phone for Facebook to use to match it to a real person.
Why Not Use Just the Pixel?
Pixel
Conversions API
Sees what the browser sees (page views, scroll, clicks)
Sees what your server sends (eg. purchases)
Can be blocked by Safari, Brave, ad blockers, iOS 14+
Cannot be blocked by any browser-level restriction
Cookie lifetime capped at 7 days on most browsers
Persistent customer identifiers
Limited to events that happen in the browser
Can report events that never happen in a browser at all
Isn’t This Complex To Setup Properly?
Honestly, yes. Setting up the Conversions API correctly is the part most people get wrong, which is why a lot of installs end up sending Meta partial or duplicate data.
If you’re non technical, the standard routes for setting this up are not straight forward:
Build it yourself - using Meta’s Graph API means a developer writing custom code, hashing identifiers, generating event IDs, handling errors, and maintaining the integration as Meta updates its API over time.
Setting it up through Google Tag Manager Server-Side means setting up a server container, learning GTM’s tag and trigger model, and configuring deduplication by hand.
Both work. Both assume you already know what you’re doing.
PixelFlow takes the technical work out of it. You drop a single script onto your site, connect your Meta Pixel, and the Conversions API is live within minutes. From there, our visual tagger lets you point at any element on your site (a button, a link, a form field, a thank-you page URL) and assign a Meta event to it. No code, no triggers to configure, no payloads to map.
We also ship platform-specific integrations for Webflow, Framer, Squarespace, WordPress, WooCommerce, Kajabi, and ClickFunnels. On these platforms PixelFlow knows what your standard events look like out of the box, so things like Add to Cart, Checkout, and Purchase track automatically without you having to tag them.
Behind the scenes, PixelFlow handles every piece of the technical setup:
Event identifier generation so deduplication works correctly
SHA-256 hashing of all customer identifiers
Payload formatting that matches Meta’s spec
Retry logic when events fail to send
Ongoing updates whenever Meta changes its API
You don’t think about any of it. You just see clean events in your dashboard and rising EMQ scores in Meta Ads Manager.
If you’ve got a developer or a GTM specialist on standby, those paths are still available to you. For everyone else, PixelFlow is what makes the Conversions API installable without it becoming its own multi-week project.
Facebook Can Find More Similar Customers to Show Your Ads To
Now that Facebook can match your events to real user, it can find more like them.
It knows up to 52,000 data points on every user, so once it can tie an event on your website to a specific Facebook user (or a few of them), it knows the patterns your buyers have in common.
It can now better display your ads to people who share those patterns, even when those people don’t fit any audience you would have thought to build manually.
This is why the quality of the conversion data you send Facebook matters so much more than it used to.
More data in, better matches out. That’s the loop the Conversions API and PixelFlow exists to feed.
Frequently asked questions
What is an event_id and why does it matter?
The event_id is a unique string attached to every event that the Pixel and the Conversions API both send to Meta. When Meta receives two events with the same event_id, it knows they describe the same real-world conversion, even though they arrived through different channels. Without a shared event_id, Meta would count a single purchase twice, inflating your numbers and making your CPA look misleadingly low.
What customer data does the Conversions API send?
Whatever identifiers you pass with each event - hashed email, hashed phone, name, IP address, user agent, location, external_id, fbp, and fbc. The more you send, the higher your Event Match Quality score. At minimum, hashed email, fbp, IP, and user agent usually pushes EMQ to 7/10 or higher.
Is the customer data sent to Meta secure?
Yes, as long as it's hashed before it leaves your server. Personal identifiers must be SHA-256 hashed before transmission, so Meta never sees raw values, only hashed versions it compares against its own records to find matches.
Does the Conversions API replace the Facebook Pixel?
No. Meta has said the Pixel and the Conversions API are complementary, not interchangeable. The Pixel captures browser-side behaviour while CAPI captures server-side conversions and backs up any browser event that gets blocked. Running both gives Meta the most complete picture.
How does Meta deduplicate the events?
Mainly through the event_id. When Meta receives two events with the same event_id within roughly 48 hours, it treats them as one conversion regardless of channel. A misconfigured event_id is the most common cause of inflated CAPI numbers.
Can I see the events being sent in real time?
Yes, in Meta's Events Manager "Test Events" tab, which shows every event from both the Pixel and the Conversions API within seconds. Managed tools like PixelFlow also keep their own event log showing the exact payload and Meta's response.
Do I need to do anything to keep it running once it's set up?
For a managed tool like PixelFlow, no - once installed it runs continuously. The only ongoing work is tagging new conversion events as you add them (a new product page, a new lead funnel). If you built CAPI yourself, you'll have more upkeep: access tokens need rotation and event_id logic has to keep working as Meta changes its API.
Smarter, server-side tracking
Start sending accurate conversions today - no tag manager, no code, no developer required.
Compatible with
