Quick answer. Meta CAPI (the Facebook Conversions API) sends conversions from your server straight to Meta, bypassing the browser where ad blockers and iOS Safari kill the pixel. Setup means connecting your dataset, sending hashed events server-side, and deduplicating against the pixel with a shared event ID. Done right, it recovers 25 to 40 percent of lost conversions.
If you run Meta ads and rely on the pixel alone, you are optimizing toward incomplete data. The pixel fires in the browser, and the browser is exactly where conversion data goes to die: Safari’s Intelligent Tracking Prevention caps cookie lifetimes, ad blockers strip the request before it leaves the page, and iOS limits what gets reported at all. The Conversions API is how you get that data back.
This guide covers what Meta CAPI actually is, the four ways to install it, where a managed server-side tracking layer fits, and the deduplication and match-quality details that separate a working integration from one that quietly double-counts every sale.
What Meta CAPI is
Meta Conversions API (CAPI) is a server-to-server connection that sends customer actions, things like purchases, signups, and form submissions, directly from your backend to Meta’s servers. Instead of trusting a browser tag to report the conversion, your server reports it.
That distinction matters more every year. The Meta pixel is client-side: it runs JavaScript in the visitor’s browser and depends on third-party cookies, neither of which survives modern privacy controls. CAPI runs server-side, so it is invisible to ad blockers and unaffected by ITP or app tracking limits.
CAPI is not a replacement for the pixel. It is a complement. The pixel still captures the click and the browser context. CAPI backs it up with server-verified data Meta can trust. Run both, deduplicate them, and Meta gets a complete picture instead of a partial one. This is the same architecture behind every modern conversion API, whether you are sending to Meta, Google, or TikTok.
How Meta CAPI works
The flow is simple once you see it end to end:
- A user clicks your Meta ad. Meta attaches a click ID (
fbclid) to the destination URL. - The user lands on your site. Your page captures the
fbclidand stores it, usually in a first-party cookie. - The user converts: a purchase, a lead, a registration.
- Your server captures that event along with the click ID and any customer data you hold.
- Your server sends the event to Meta’s CAPI endpoint with hashed identifiers and the transaction details.
- Meta matches the event back to the original ad click.
- Meta uses that signal to optimize delivery, showing your ads to more people who look like the converter.
The key difference from pixel-only tracking: Meta receives server-verified conversion data, not browser-inferred guesses. Higher data quality in means better optimization out.
The four ways to install CAPI
There is no single “right” method. The right one depends on your engineering resources and how much control you need.
1. Partner or managed integration (easiest)
Effort: a few hours to a week. You use a platform that handles the API connection, hashing, and deduplication for you. This is the path most marketing teams should take, because it removes the two things that break CAPI integrations most often: incorrect hashing and missing deduplication.
Best for teams without dedicated engineers, or anyone who wants CAPI live this week rather than next quarter.
2. Server-side GTM container (intermediate)
Effort: two to three weeks. You stand up a server-side Google Tag Manager container on Google Cloud or similar, route pixel data through it, and forward events to Meta. Flexible, but you now own hosting, maintenance, and the GTM learning curve. Latency is higher than a direct call.
Best for agencies juggling complex event routing across multiple clients.
3. Direct API integration (most control)
Effort: four to eight weeks. Your engineers build a custom endpoint that calls Meta’s CAPI directly. Maximum control, lowest latency, and you own every piece of error handling, retries, and hashing.
Best for enterprise SaaS and large e-commerce teams with engineers to spare.
4. Native platform integration (limited)
Some platforms (Shopify, BigCommerce, WooCommerce) ship a built-in Meta CAPI toggle. Zero setup, but little control over the payload and no help with deduplication against an existing pixel. Fine as a starting point, rarely enough on its own.
The opinionated take: most “build it yourself” CAPI projects fail not on the API call, which is trivial, but on the boring parts. Hashing user data correctly, keeping event IDs consistent across pixel and server, and monitoring for silent data loss. If those are not handled, a hand-rolled integration is worse than no CAPI at all, because it inflates your numbers with duplicates. Pick the method that handles those parts for you unless you have a specific reason not to.
Where Convultra fits today
Convultra is managed server-side conversion tracking, and it is worth being precise about what it does for Meta right now: Meta Conversions API forwarding is coming soon, not live. What works today is the capture half of the problem, which is the half most hand-rolled CAPI projects get wrong.
Step 1: Install the script
Add one async tag before the closing </head>, with the project key from your dashboard:
<script async src="https://cdn.convultra.com/ultra.min.js" data-convultra-key="proj_…"></script>That is the whole client install, about 10KB. It captures page views and persists every click ID it sees on landing (fbclid, gclid, gbraid, wbraid, msclkid, ttclid, oppref) in first-party storage, so the Meta click from last Tuesday is still attached to the purchase on Friday. Setup takes about five minutes.
Step 2: Record conversions
Fire the conversion where it happens:
Convultra.trackPurchase({
value: 99.99,
currency: 'USD',
orderId: 'txn_12345'
});The conversion is recorded server-side with the persisted click IDs attached. Any personal data detected in the payload is hashed with SHA-256 before it is sent to any ad platform, and the order ID is what deduplication keys on, so a retry or a double-fired thank-you page never records a sale twice.
Step 3: What forwards today, and what is coming
Google Ads delivery with enhanced conversions and OpenAI Ads delivery are live, and the delivery log shows every conversion sent with the platform’s response. Meta Conversions API forwarding is coming soon, along with Microsoft Ads and TikTok. Until it ships, the conversions and fbclids Convultra captures are recorded and ready, you keep sending to Meta through whichever of the four install methods above you use today, and the recovery report shows how many conversions your pixel alone is missing in the meantime.
Event matching and deduplication
These two concepts decide whether CAPI helps or hurts.
Match quality is how well Meta can tie your hashed event to a real user. The more identifiers you send (hashed email is the single most important, then phone, name, and location), the higher the match rate and the better the optimization. A purchase event with email, phone, and location will match far more reliably than one carrying only a country code.
Deduplication prevents the same conversion being counted by both the pixel and CAPI. The fix is a shared event_id that is unique per conversion and identical across both sources:
// On the checkout success page
const eventId = 'txn_' + orderId;
// Pixel
fbq('track', 'Purchase', { value: 99.99, currency: 'USD', event_id: eventId });
// Server: whatever posts to CAPI sends the same event_id
// { event_name: 'Purchase', event_id: eventId, custom_data: { value: 99.99, currency: 'USD' }, user_data: { em: [sha256(email)] } }Meta sees the same event_id from both paths and counts it once. Get this wrong and your reported conversions inflate, your ROAS looks artificially strong, and the algorithm optimizes against noise.
Common mistakes to avoid
The failure modes are predictable, which is good news. Watch for these:
Skipping deduplication, which double-counts every conversion. Sending raw email or phone instead of SHA-256 hashes, which Meta rejects and which creates a compliance problem. Sending too few identifiers, which tanks match quality. Inventing event names instead of using Meta’s standard set (Purchase, Lead, CompleteRegistration, AddToCart, InitiateCheckout, ViewContent). Firing events minutes late instead of within seconds. And shipping a test_event_code to production, which routes real sales into your test dataset.
Every one of these is invisible until you look. None of them throws an obvious error. That is exactly why monitoring conversion counts against your own server logs is not optional.
Where CAPI fits in your stack
Meta CAPI is one Conversions API among several. The same server-side pattern feeds google ads conversion tracking, TikTok Events API, and Microsoft Ads. Building each one by hand means maintaining a separate integration per platform. Routing them through one server-side layer means you capture the conversion once and fan it out everywhere, which is the entire premise of cookieless tracking: collect first-party, send server-side, stop depending on the browser.
If you are setting up CAPI in isolation, you are solving a fraction of the problem. The lost-conversion issue spans every ad channel you run, not just Meta.
Recover the conversions you are already paying for
Meta CAPI is no longer a nice-to-have. If you run Facebook ads on the pixel alone, you are losing 25 to 40 percent of your conversion data and optimizing the rest toward a distorted picture. Start a free Convultra trial and install the script today: click IDs are persisted and Google Ads and OpenAI Ads delivery are live now, so the conversions you capture are ready to forward the day Meta CAPI ships.