Meta CAPI Gateway: What It Is and When to Use It

You open Events Manager to finally set up the Conversions API, and Meta offers you a shortcut: "Set up with Conversions API Gateway. No code required." Thirty minutes later you have a CloudFormation stack running in your AWS account and events flowing. It feels like you just implemented server-side tracking.

You implemented half of it. The Gateway is a real product with a real use case, but most store owners who click that button do not know what it actually does, what it cannot do, and what they will pay AWS for every month. Here is the whole picture.

What Is Meta CAPI Gateway?

Conversions API Gateway is Meta's self-serve, no-code way to run the Conversions API. Instead of writing server code that sends events to Meta, you deploy a pre-built Meta application into your own cloud account. Meta's stated goal is cutting integration time "from weeks to hours or even minutes."

Technically it is two modules running on your infrastructure:

1. A middleware module that receives events from your visitors' browsers (sent by the Meta Pixel to your Gateway's endpoint instead of only to Meta) and transforms them into Conversions API events.
2. An admin portal, a web interface where you monitor event volume, manage domains and pixels, and maintain the instance.

Read that first module again, because it is the key architectural fact: the Gateway's input is the browser Pixel. It does not connect to your store's database, your payment processor, or your CRM. It relays and enriches what the browser fired, over a first-party connection.

Setup and Real Cost

Setup starts in Events Manager: Settings, then "Set up with Conversions API Gateway." The flow launches a stack in your own cloud account. Supported hosts are AWS (EKS or ECS Express) and, more recently, Google Cloud. Stack creation takes 30 to 40 minutes, and event verification anywhere from 5 minutes to 2 hours. Meta recommends a custom subdomain (something like capig.your-store.com), which routes events first-party.

The software itself is free. Meta is explicit that "the only cost of the Conversions API Gateway is the associated cloud resource or partner fees." What that means in practice:

Maintenance is light: the Gateway defaults to automatic infrastructure and software updates. But "light" is not "none". It is a piece of infrastructure in your cloud account, and when event volume drops to zero on a Tuesday, you are the one who notices or does not.

There is also a multi-account mode aimed at agencies: one Gateway instance can serve Conversions API integrations for many client ad accounts, pixels, and domains, which beats deploying and paying for one stack per client.

What the Gateway Fixes, and Where It Stops

The Gateway earns its keep in one scenario: your Pixel fires, but the event does not reach Meta reliably. Routing events through your own first-party subdomain gets them past most network-level ad blocking (they go to your domain, not facebook.com) and helps with Safari's cookie limits. The Gateway also automatically generates event_id values, so deduplication between Pixel and server events works out of the box: Meta matches events on event_id plus event_name within a 48-hour window and keeps the first one. For getting more of your browser events to Meta, it does the job.

Where it stops is built into the architecture. The Gateway converts browser events into server events, so anything the browser never fired is out of reach:

• Server-only events. A phone order entered in your backoffice, a subscription renewal, a payment that confirms after the thank-you page: none of these happen in a browser, so a Gateway cannot send them.
• CRM enrichment. A direct integration can attach whatever your server knows (customer lifetime value, hashed CRM identifiers). The Gateway works with what the Pixel collected on the page.

And the bigger one, the reason this post exists: the Gateway feeds Meta, it does not give you a number. Everything it does is in service of Meta's algorithm bidding better. Once it is running, your only report of which campaign made money is still Meta's own dashboard.

That is the honest comparison with the other CAPI setup routes: direct API integration gives full control and true server-side events at development cost; server-side GTM sits in the middle; the Gateway is the fastest route but stays tethered to the browser. Meta's own positioning matches: the Gateway targets "performance marketers with some technical expertise" and no developer resources.

Whichever route you take, the event payload rules are the same. Every event needs event_name, event_time, action_source, and user_data; website events additionally need client_user_agent and event_source_url. Your Event Match Quality score rises with hashed email (em) and phone (ph), plus client_ip_address and name fields. Hash emails and phones; never hash IP address, user agent, fbc or fbp.

Where Order-Based Attribution Fits

Enalitica sits on the measurement side, and it does not compete with feeding Meta. It sends order-based conversions to Meta CAPI server-side from the confirmed WooCommerce or Shopify order (value, currency, hashed email, fbclid, fbp/fbc, with a deterministic event_id so nothing double-counts against your Pixel), so Meta's algorithm gets clean data the same way a Gateway would. Better data in, more sales out. That part helps everyone.

The difference is the second half. A Gateway improves how many events reach Meta, but it still leaves your only scoreboard as Meta's own dashboard, the one that counts view-through conversions and cannot see what Google did. Order-based attribution gives you an independent number: every euro of revenue traced to a real order in your store, reconciled to what actually landed in the bank, with the campaign and keyword behind it. You sell more, and you can see how much more, and from where. Signal for the algorithm, orders for the truth. You want both, and they are not the same job.

If you run WooCommerce and want CAPI feeding Meta from your actual orders plus a number you can check Meta against, book a demo and we will show the event flow end to end on your store's data.

Frequently Asked Questions

Do I still need the Meta Pixel if I run CAPI Gateway?

Yes. The Gateway is fed by the Pixel; without the browser script it has nothing to relay. This is different from a direct server integration, which can send events with no Pixel at all. Meta's recommended setup in all cases is redundant: Pixel plus server events, deduplicated via event_id.

Does CAPI Gateway improve my Event Match Quality score?

It can, moderately. The Gateway forwards richer, first-party-collected browser parameters (like fbp and page context) more reliably than a blocked or throttled Pixel would. But EMQ is driven hardest by hashed customer identifiers like email and phone, and the Gateway can only send what the visitor's browser session exposed. Server integrations that pull identifiers from your order or CRM data have a higher ceiling.

Can I run CAPI Gateway for multiple stores or clients?

Yes. The multi-account version of the Gateway is built exactly for this: agencies and platforms can serve multiple ad accounts, pixels, and domains from one deployed instance, with per-client management in the admin portal. Costs stay roughly flat while client count grows, which changes the economics compared to one stack per store.

What happened to the Offline Conversions API?

Meta discontinued the standalone Offline Conversions API in May 2025. Offline events (in-store purchases, phone orders) now go through the standard Conversions API with action_source set accordingly. This is worth knowing in the Gateway context: offline events by definition never touch a browser, so they are another category the Gateway cannot carry and a direct integration can.

Is the Gateway GDPR-compliant by default?

The Gateway runs in your cloud account and relays events your Pixel was permitted to fire, so consent is enforced upstream: if your consent banner blocks the Pixel until opt-in, the Gateway receives nothing for non-consented visitors. Deploying a Gateway changes where events travel, not what you are allowed to collect. Your consent mode and privacy policy do the compliance work, same as with every other CAPI route.