Meta Conversions API Setup: Step-by-Step CAPI Implementation

By Corey Frankosky · Last Updated August 28, 2026

Browser tracking alone does not capture all of your conversions any more. Ad blockers, browser privacy restrictions, and short cookie lifetimes mean a meaningful share of your purchases and leads never make it back to Meta, and the algorithm optimizes on what it can see. The Conversions API fixes that by sending events from your server instead of the browser. In this guide you will pick the right implementation route for your setup, get the deduplication right so you are not double counting sales, and verify the whole thing in Events Manager before you trust a single number.

1What the Conversions API Actually Fixes

The Meta Pixel runs in your visitor's browser. That means anything the browser blocks, the Pixel loses. Ad blockers stop it outright, tracking prevention in Safari and Firefox limits what it can store, and cookie lifetimes have been cut short enough that a visitor who converts a week later often looks like a brand new person.

The Conversions API sends the same events from your server directly to Meta. No browser involved, so none of those restrictions apply. Your server already knows the order happened, so it can report it reliably.

The important part is that this is not a replacement for the Pixel. You run both. The browser catches signals the server does not have, like the full click context, and the server catches conversions the browser loses. Run them together and deduplicate, which is what most of this guide is about.

Question to Answer:

Do you know what share of your conversions Meta currently reports compared to what your own backend recorded?

2Datasets, Not Pixels

Meta renamed what used to be called a Pixel. In Events Manager you now work with a dataset, and both your browser events and your server events go into the same one. The Pixel ID you already have is the dataset ID. Nothing broke, and you do not need to create anything new.

This matters for setup because older guides tell you to create a separate server-side pixel. Do not. If your browser events and server events land in two different datasets, Meta cannot match them, you lose the deduplication, and your reporting doubles.

You will need two things from Events Manager before you start: your dataset ID, and an access token for the Conversions API. Both live under the dataset's settings.

3Pick Your Implementation Route

There are three realistic routes, and the right one depends on your platform and how much control you need. Pick the simplest one that covers your events.

Most businesses should stop at the first row. If you are on Shopify and someone is quoting you for a custom Conversions API build, ask them what the native integration does not cover first.

4Route 1: Platform Integration

If you are on Shopify, the Conversions API comes through the Facebook and Instagram sales channel. The setup is short.

1. Install the Facebook and Instagram channel. Add it from the Shopify admin and connect the Business Manager account that owns your dataset.
2. Connect the right dataset. During setup you pick which dataset to send to. Choose the one your Pixel already uses.
3. Set data sharing to Maximum. This is the setting that turns on server-side events. On the lower settings you get browser events only, which is the whole problem you are trying to solve.
4. Accept the customer data terms. Meta will not accept hashed customer data for matching without this.
5. Check the events list. Confirm Purchase, Add to Cart, and Initiate Checkout are all mapped before you call it done.

Shopify sends the same event ID for the browser and server copy of each event, so deduplication is handled without you touching anything. That is the main reason to prefer this route.

Question to Answer:

Is your Shopify data sharing setting on Maximum, or did it get left on the default?

5Route 2: Conversions API Gateway

The Gateway is Meta's hosted option for sites that have a Pixel but no supported platform integration. It watches your Pixel events and sends a server-side copy of each one to Meta automatically.

You set it up from Events Manager, point it at a subdomain of your site, and Meta runs the infrastructure. Because it is mirroring your existing Pixel events, it inherits your event names and parameters, and deduplication is handled for you rather than something you configure.

Two things to know before you choose it. It is a paid, hosted service, so there is an ongoing cost that scales with volume. And because it mirrors the browser, it does not fix events the browser never fired in the first place. If your Pixel is missing purchases because of a checkout that does not run your Pixel, the Gateway will miss them too.

6Route 3: Server-Side Google Tag Manager

Server-side GTM makes sense when you are sending conversions to several platforms and want one place to manage it, or when you have custom events a platform integration does not cover.

You run a server container, route your site's data through it, and add a Meta Conversions API tag that forwards events to your dataset. If you have not set up GTM at all yet, start with my guide on installing Google Tag Manager, Analytics 4, and Search Console.

This is the route where deduplication becomes your job. Nothing generates a shared event ID for you, so you have to pass one deliberately. That is the next section, and it is where most custom implementations go wrong.

7Deduplication: The Part Everyone Gets Wrong

When you run the Pixel and the Conversions API together, every conversion gets reported twice, once from the browser and once from your server. Meta will collapse those into one event only if you tell it they are the same event. If you do not, you get double counted sales, inflated ROAS, and an algorithm optimizing on numbers that are not real.

Three things have to match between the browser event and the server event.

• The event ID. Generate one unique ID per conversion and send the identical value in both the Pixel call and the API call. This is the field Meta actually deduplicates on.
• The event name. Purchase and purchase are not treated as the same event. Match the case and spelling exactly.
• The click identifiers. Pass the fbp browser ID and the fbc click ID from the browser through to your server event. Without them the server event cannot be tied back to the ad that earned the click.

The practical approach is to generate the event ID server-side when you render the page, use it in the Pixel call, and store it with the order so the server event can send the same one. Do not generate it randomly in two places and hope they line up, because they will not.

The fastest way to know you got this wrong is a sudden jump in reported conversions with no change in actual revenue. If Meta says you doubled and your bank account did not, look here first.

Question to Answer:

Does your Purchase event send the same event ID from the browser and the server, and can you prove it in Events Manager?

8Event Match Quality

Event Match Quality is Meta's score for how well it can tie your events to real people. You will find it per event inside your dataset. The higher it is, the better Meta can attribute conversions and find similar buyers.

The score is driven by how many customer parameters you send and how reliable they are. Hashed email is the single biggest contributor, with hashed phone number next, followed by name, city, state, zip, and country. Everything is hashed before it leaves your server, so you are not sending raw customer data to Meta.

Send everything you legitimately have at the point of conversion. On a purchase you usually have email, phone, name, and a full billing address, and there is no reason to send only the email. On a lead form you may only have email and phone, and that is fine. If your score sits low, the usual cause is a checkout that only passes an email, or a server event firing before the customer details are available.

Do collect consent properly before you send any of it. My guide on Meta Pixel consent mode covers how that fits together.

9Verify It in Events Manager

Do not trust the setup wizard telling you it connected. Check the data.

1. Open your dataset and go to the Events tab. Each event shows its connection method. A correctly deduplicated event reads as Server and Browser, not two separate rows.
2. Run a real test conversion. Use the Test Events tool, then place an actual order and watch it arrive.
3. Compare counts to your own records. Take yesterday's orders from your backend and compare against the Purchase count in Events Manager. They should be close. Meaningfully higher means a deduplication problem.
4. Check the diagnostics tab. Meta flags missing parameters, deduplication problems, and events arriving too late here before they show up as bad performance.
5. Look at Event Match Quality per event. Fix the low scorers by sending more customer parameters.

Give it a few days of real traffic before you judge the numbers, and re-check the diagnostics tab after any change to your checkout or theme. Tracking breaks quietly, usually the week after someone edits a template.