If you run Meta ads, your tracking has probably lived in the browser for years: a pixel fires on the thank-you page, Meta records a conversion, and your dashboard fills up. That model worked when browsers were permissive and everything happened on your website. Neither is true anymore. The Conversions API, usually shortened to CAPI, is Meta's answer: a way to send conversion events from your server directly to Meta instead of relying on a script in the visitor's browser.
This guide covers what CAPI is, how deduplication and match quality work, and how to decide whether you need it.
Why the browser pixel misses conversions
The Meta pixel is a piece of JavaScript that runs in the visitor's browser. Anything that stops that JavaScript from running, or strips the cookies it depends on, silently deletes conversions from your reporting. The usual suspects:
- Ad blockers and privacy extensions block requests to Meta's domains outright. The pixel never loads, so the event never fires.
- Browser tracking prevention such as Safari's Intelligent Tracking Prevention caps the lifetime of cookies set by scripts, which shortens the window in which a returning visitor can be recognised.
- Consent banners often keep marketing tags off until the visitor opts in. Many visitors never do.
- App and device switches break the chain entirely. A lead who clicks your ad on a phone, then converts later on a laptop, or inside Telegram, WhatsApp or a broker's back office, is invisible to a pixel that only lives on your website.
None of these failures produce an error. The conversion simply does not appear, your reported ROAS drops, and Meta's optimization system gets a thinner, more biased sample of who actually converts.
The iOS 14.5 and ATT context
Apple's App Tracking Transparency framework, rolled out with iOS 14.5, required apps to ask permission before tracking users across apps and websites. A large share of users declined, which cut off much of the device-level signal Meta previously used to connect ad clicks to later conversions on iOS. The practical effect for advertisers was well documented at the time: underreported conversions, delayed reporting, and weaker optimization for iOS-heavy audiences.
ATT did not kill browser tracking by itself, but it pushed the industry toward a clear conclusion: measurement that depends entirely on the client device is fragile. Server-side event delivery is the durable path, because your server is not subject to a browser's cookie policy or an ad blocker's filter list.
What the Conversions API actually is
CAPI is an HTTP API. Instead of the browser firing an event, your server (or a tracking platform acting on your behalf) sends a POST request to Meta containing the same kind of event the pixel would have sent: an event name such as Purchase or Lead, a timestamp, customer information for matching, and optional value data.
A CAPI event has three important parts:
- Event details:
event_name,event_time,event_source_urland anaction_sourcethat tells Meta where the event happened (website, app, offline, and so on). - User data: identifiers used to match the event to a Meta account, including hashed email (
em), hashed phone (ph), the pixel cookies_fbpand_fbc, click ID (fbclid), IP address and user agent. Personal identifiers are hashed with SHA-256 before sending. - Custom data: order value, currency, content IDs, or whatever your event needs to carry.
Because the event originates on your server, it fires whether or not the visitor's browser cooperated. It can also fire days after the click, which matters for funnels where the real conversion, a funded account or a repeat order, happens long after the website visit. That is exactly the model behind FlowTracker's Attribution & CAPI product: capture the click ID once, follow the lead server-side, and send the conversion back to Meta when it actually happens.
Deduplication: the event_id handshake
Most real-world setups run the pixel and CAPI together, which means Meta can receive the same conversion twice. Deduplication is how Meta collapses those into one. The mechanism is simple: both the browser event and the server event carry the same event_name and the same event_id. When Meta sees a matching pair within the deduplication window, it keeps one and discards the other.
Generate the event_id once, at the moment the conversion happens, and pass that single value to both the pixel call and the server event. Teams that generate IDs independently on each side end up with double-counted conversions and inflated ROAS, which is worse than no CAPI at all because it looks like good news.
Events Manager shows whether events arrived from browser, server or both, and whether they merged correctly.
Match quality: why some events count and others do not
A server event is only useful if Meta can match it to a person. Meta scores this as Event Match Quality (EMQ) in Events Manager. The score reflects how many identifiers you send and how reliable they are. Rough hierarchy:
| Identifier | Notes |
|---|---|
fbc / fbclid (click ID) | Strongest link back to the specific ad click. Capture it on landing and store it. |
| Hashed email and phone | Strong, stable identifiers. Collect them as early in the funnel as you can. |
fbp cookie | Browser-level identifier, useful but subject to cookie lifetime limits. |
| IP address and user agent | Weak alone, helpful in combination with the others. |
Higher match quality means more attributed conversions and a fuller picture for Meta's delivery system to learn from. If your EMQ is low, the fix is almost always upstream: capture the click ID reliably, and collect an email or phone number before the lead leaves your page.
FlowTracker captures click IDs, follows leads across app switches and fires deduplicated CAPI events automatically, from opt-in to FTD or order.
When do you actually need CAPI?
Honest answer: not every advertiser needs it on day one. If you sell a low-priced product and convert on-site within minutes of the click, a pixel-only setup may report acceptably. You need CAPI when any of these apply:
- Conversions happen off your website. Leads who convert inside Telegram or WhatsApp, in a broker's portal, over the phone or in person are unreachable by a pixel. This is the norm in forex and trading funnels, where the event that matters is a deposit in a third-party system.
- Conversions are delayed. Trials, funded accounts, subscription upgrades and repeat purchases can land days or weeks after the click, outside the pixel's practical reach.
- High-value, low-volume events. When one conversion is worth hundreds or thousands, losing even a handful to ad blockers meaningfully distorts your numbers.
- You optimise on deep-funnel events. Feeding Meta the real revenue event instead of a shallow proxy changes who the algorithm goes looking for.
How teams implement it
There are three common routes. Direct integration means your developers call the API from your backend; maximum control, most work, and you own dedup and retries. Server-side tag managers give you a middle layer you host and maintain. The third route is a tracking platform that already speaks CAPI: it captures the click, holds the identifiers, and fires the event when the conversion arrives from your CRM, payment provider or broker. FlowTracker takes this route, with 34+ broker integrations plus Stripe and Shopify feeding conversions into CAPI without custom code.
Whichever route you take, the fundamentals in this guide stay the same: get the click ID, hash the identifiers, send one event_id to both sides, and check Events Manager until dedup and match quality look right. For the broader picture of where server-side tracking fits alongside pixels, read our server-side tracking vs pixels guide, and if your funnel runs through Telegram, the Telegram attribution guide covers the messiest part of the journey.