Conversions API vs CAPI Gateway vs GTM Server-Side: Which One Do You Need?

Meta gives you three ways to send events from a server, and most articles describe them as if they were the same thing at different prices. They are not.

Short version: if Meta is your only destination and you want it working this week, use the CAPI Gateway. If you need one pipeline for several platforms, use a GTM server container. If you have engineering capacity and unusual requirements, call the Conversions API directly. Everything below is about picking the one you can still live with in a year.

What each option actually is

The Conversions API

The Conversions API is Meta's server endpoint. You send it events with the same names as your pixel events, plus identifiers and an event ID so Meta can match and deduplicate. There is no container and no vendor in the middle: your code builds a payload and posts it.

That means full control, and full responsibility. Retries, batching, error handling, rate limits and schema changes are yours to maintain. On a Next.js or Payload build with a server runtime, this is often less work than people expect. On a WordPress site with no developer, it usually is not.

The Conversions API Gateway

The gateway is a Meta-managed container that runs in your own AWS account. You create it from Events Manager, choose an instance size based on event volume, and get an endpoint. Events arrive from the browser and from your server, and the gateway forwards them to Meta.

You get a maintained container and a first-party subdomain option, which survives more browser blocking than a request to a Meta domain. You also get a monthly AWS charge and an account nobody in marketing will remember. It handles Meta and nothing else, which is the point and also the limitation.

Whatever you choose, the browser pixel still has to be correct, because it supplies most of the identifiers the server path relies on.

A GTM server container

A server container is a Google Tag Manager container running on infrastructure you control, such as Cloud Run, App Engine or a Cloudflare Worker. It receives events from the web container and from your server, runs whatever logic you put in it, then sends to Meta, Google, TikTok, LinkedIn or your own warehouse.

This is the option with the widest reach and the highest operational load. You own the hosting, the container configuration, the custom templates and the person who understands them. When it breaks at 11pm on a Saturday, it is your problem.

The comparison that matters

Option	Effort and hosting	Best fit
CAPI (direct)	Code; no new hosting	Dev team, specific needs
CAPI Gateway	Wizard; AWS instance	Meta-only, small business
GTM server	Container; cloud hosting	Multi-platform, in-house support

When the gateway is the right answer

• Meta is where most of your paid spend goes, and the other platforms are an afterthought
• Your site is WooCommerce or a small custom build and nobody wants to own a container
• You want a first-party endpoint without a project
• You need the event loss fixed this month

It is a bad fit when you plan to add TikTok or LinkedIn next quarter, when events need transforming before they leave, or when nobody will watch an AWS bill.

When a GTM server container is the right answer

• You send to two or more platforms and want one pipeline
• You need to enrich or filter events before they go anywhere
• You already have someone who understands GTM
• You want events landing in BigQuery or your own store as well

It is a bad fit when GTM is a black box to everyone in the business. A server container that nobody can debug is worse than no server container.

If you want a server container but not the ops

The usual objection to a server container is not the container, it is the hosting: Cloud Run, App Engine or a Worker, plus someone to patch it. Managed hosts remove that layer, and Stape is the one I recommend. It runs the container for you on EU or global infrastructure, gives you a custom subdomain and a debug view, and charges a fixed monthly fee tied to request volume instead of cloud billing that moves with traffic.

The same account runs a hosted Meta CAPI Gateway, which is useful when a client wants server-side Meta events without an AWS account.

What you give up is control and portability. Events pass through a third party, which is a data-handling decision worth writing down, and leaving means re-pointing the endpoint and re-validating every event. For a small business that will never run its own cloud account, that is usually a fair trade. For a business with a platform team, it usually is not.

The decision does not change though. You are still choosing an owner. A managed host just makes it possible to choose a server container that one person can actually support, without also choosing cloud engineering.

When direct CAPI is the right answer

• You have a server runtime and a developer who can own the code
• Events already exist in your backend and are awkward to reconstruct in a container
• You need tight control over batching, retries and identifiers
• You do not want another vendor in the path

It is a bad fit when nobody can maintain it. An unmaintained integration rots quietly, and the rot looks exactly like a tracking decline.

The things that actually decide it

Deduplication is the failure mode, not delivery. Most broken setups deliver every event and count some of them twice. Same event name, same event ID, both paths. Test with real traffic, not the test events tool.

Match quality comes from identifiers. Hashed email, phone and a stable external ID do more for your match rate than any transport choice. A gateway forwarding a cookie is worse than a direct call with a customer record attached.

Consent order matters. If your consent banner blocks the browser event but the server path fires anyway, you have a privacy problem and Meta may discount the data. Decide what fires before consent and enforce it in one place.

You are choosing an owner, not a feature. Every option needs a named person who checks it monthly. Pick the one that person can actually support.

What I would do for a Perth small business on WooCommerce

Gateway, with deduplication built properly and a documented handover. Not because it is technically superior, but because it is the only option that does not create a container nobody maintains. If the business later adds TikTok or a warehouse, that is the moment to move to a server container, and the event work already done transfers.

If you are on Next.js or Payload and already have a server runtime, I would usually skip the gateway and call the Conversions API directly, unless the volume is high enough that a managed container is genuinely cheaper than the engineering time.

Either way, if you sell products, the product catalogue has to agree with the pixel on product IDs, or the reports will disagree even when the events are perfect.

If you want this set up properly

I do this as a paid diagnostic first, then a fixed-price quote: audit the current setup, choose the path that fits your stack, build deduplication, then verify against your real orders rather than Meta's dashboard alone. There is more on the Meta CAPI Gateway setup page, and this post on event_id deduplication covers the part that breaks most often.

If you already have tracking and just do not trust it, the GA4 and GTM audit is where that starts. Either way, get in touch and tell me what Meta reports versus what you actually sold. That gap is the diagnosis.