Yes, Meta CAPI is free. Meta doesn't charge for sending events through its Conversions API. The cost is in running it: a partner platform's plan, the cloud or partner fees for Meta's Conversions API Gateway, or the developer time and server for a direct integration.
For a seller on paid traffic, the setup that matters is the one that sends every purchase and upsell from where the order is recorded, with the click ID and hashed customer data, and the same event ID as the pixel.
I'd pick the method by where your sale happens, and only then look at the price.
"Is it free?" is a fair question, because most of the answers online come from companies selling a CAPI tool. The API itself costs nothing to call. What you pay for is the plumbing around it, and the cheapest plumbing isn't always the one that sends Meta the sales you care about. Here's what each option costs, what the setup involves, and where people lose sales without noticing.
What Meta CAPI is, in one paragraph
The Meta pixel reports events from the visitor's browser. The Conversions API reports them from a server: your own, a platform's or a gateway's. Meta processes server events the same way as pixel events, for reporting and for optimization. It recommends running both and sending the same events through each, because the pixel can lose events to network problems and page loading errors (Meta best practices). Ad blockers and closed tabs make the gap wider. For anyone optimizing campaigns on purchases, a purchase Meta never hears about is a purchase the algorithm can't learn from.
What Meta CAPI costs to run
Meta's own documentation says the integration methods "vary by level of effort, cost, and the features they enable" (Meta, get started). In practice there are three ways in, and the bill looks different for each.
| Method | What you pay for | Effort | What it sends |
|---|---|---|---|
| Partner integration (your store, funnel or checkout platform) | Usually part of the platform you already pay for | Connect a pixel ID and a token | The events the platform records, often including purchases from its own checkout |
| Conversions API Gateway | Cloud hosting in your own AWS or Google Cloud account, or a hosting partner's fee | No code; set up and maintain a cloud service | Copies of the events your pixel sees in the browser |
| Direct integration | Developer time and the server it runs on | Build, test and keep up with Meta's changes | Anything your server knows about, including events that happen after the visit |
On the Gateway, Meta is explicit: "The only cost of the Conversions API Gateway is the associated cloud resource or partner fees" (Meta, Conversions API Gateway). It needs no code and Meta generates the event IDs for you. The catch is in the last column. The Gateway forwards what the pixel saw in the browser. If a purchase happens on your server, like a one-click upsell charged to the card on file, or a sale your call center closes the next day, the browser never sees it and the Gateway has nothing to forward.
That's why I wouldn't choose on price alone. For a funnel with upsells and late sales, the right setup is the one that sends events from where the order is recorded, and that's usually your checkout platform or your own server.
How to set up Meta CAPI
Whichever method you choose, Meta asks for the same pieces. A partner integration fills most of them in for you; a direct integration means building each one.
- Use your existing pixel ID. Meta asks for the same pixel ID for browser and server events.
- Generate an access token. In Events Manager, open the pixel's settings and generate a token under Conversions API. Meta creates a Conversions API app and system user for you, and there's no app review.
- Choose the events. For a funnel: Purchase for every order, including upsells, plus the earlier steps you optimize on, such as InitiateCheckout or Lead.
- Send the required fields. Each event needs
event_name,event_time,action_source, and for website eventsevent_source_url, plusvalueandcurrencyon purchases. - Add customer information. Email and phone hashed with SHA-256, the
fbcvalue built from the fbclid click ID, thefbpbrowser ID, the IP address and the user agent. - Deduplicate with the pixel. Give the pixel's event and the server's event the same name and the same event ID.
- Test, then watch the score. Send test events with the Test Events tool, then check Event Match Quality (EMQ) for each server event in Events Manager.
If your funnel starts on a presell or an advertorial and the checkout sits on another domain, check step 5 twice. The click ID arrives on the first page, and if it doesn't travel with the visitor to the checkout, every purchase reaches Meta without the one value that ties it to the ad.
Mistakes that quietly lose sales
None of these throw an obvious error. The events arrive, the dashboard looks busy, and the campaign optimizes on less than you think.
- Double counting. If the pixel and the server both send Purchase without a shared event ID, Meta can count the sale twice and your reported ROAS looks better than it is. Meta discards the second copy only when the event name and ID match, within 48 hours (Meta, deduplication).
- Losing the click ID. Redirects, link shorteners and cross-domain checkouts drop the fbclid. The sale still goes out, with nothing tying it to the ad.
- Sending late sales too late.
event_timecan be at most 7 days in the past, and if one event in a batch is older, Meta rejects the whole request and processes none of it (Meta, server event parameters). Send call-center and delayed sales as they happen. - Unhashed or badly formatted data. Meta's SDKs hash for you. Without them, normalize and hash with SHA-256 yourself, or the match rate drops.
- Only the front-end sale. If upsells don't go out as purchases, Meta optimizes toward buyers of the cheap first product and never sees which ads bring the buyers who take the upsell.
The last one is the expensive one for upsell funnels. Two ads can bring in the same number of front-end buyers and very different revenue per buyer, and Meta can only tell them apart if the upsells reach it.
Meta CAPI in ElasticFunnels
In ElasticFunnels the checkout, the upsells and the order record live in the same place, so the server that records the sale is the one that tells Meta about it. That's the setup I'd want for any funnel with upsells, and it's included on every plan.
- Connect with a pixel ID and a system-user token. The Meta Conversions API integration needs no Meta app review.
- Purchases and upsells from the server. Each sale and each upsell goes to Meta as it's recorded, with SHA-256 hashed customer data and the
fbcvalue built from the fbclid captured on the visit. - ROAS counted on sales. Meta ad spend syncs back, so the Campaigns report shows spend next to the revenue your checkout recorded, per campaign, ad set and ad.
For the click ID side, what is fbclid explains how it becomes the _fbc cookie and how to keep it through a funnel. Marketing attribution models covers why Meta's numbers and your own never quite match.
- Don't pay for a CAPI tool that only mirrors your pixel if your upsells and late sales happen on the server. It sends Meta the part it already had.
- Check deduplication before you trust a single ROAS number. A setup that double counts makes every campaign look better than it is.
- Follow one real purchase through, from the ad click to Test Events, before you scale. A short check now beats a month of optimizing on half the data.
- A high match score on a funnel that drops the click ID is still a broken setup. Check the
fbcfield on real events.
I spent nine years as CTO of a direct-response company, and one line from that time still sums up tracking for me: postbacks that broke when URLs changed. The Conversions API is the modern version of that problem. It's free to use and easy to switch on, and that's exactly why it's easy to get wrong without noticing. Spend the time on which sales reach Meta, and with what attached to them. That decides what your campaigns learn.
