TL;DR
The Conversions API Gateway (CAPIG) and a tracking app both solve the same problem: getting a reliable, server-side Purchase into Meta that survives ad blockers and iOS restrictions. They differ in who runs the plumbing. The Gateway is Meta's own middleware, and you install it into your cloud account as an AWS CloudFormation stack, then operate it, because patching, uptime, region, and the monthly cloud cost are all yours [2]. A tracking app moves that entire surface to the vendor and connects through the Shopify Admin in minutes. For a single Shopify store at normal Meta spend, an app or the native channel already sends the same hashed server-side Purchase, so the Gateway earns its keep only for a narrow profile: a large advertiser with an infrastructure team, a data-residency rule, or several properties feeding one gateway.
Key Takeaways
- The Conversions API Gateway is Meta-provided middleware you self-host in your own AWS or GCP account. It is not hosted by Meta and it is not an App Store install.
- Setup runs through Events Manager and deploys an AWS CloudFormation stack in your account, which takes roughly 30 to 40 minutes to create before you configure anything [2].
- Meta charges nothing for the Gateway software. Your cost is the cloud resources it runs on, and that bill plus its uptime are yours to manage [1].
- A Shopify tracking app sends the same server-side Purchase to Meta with
event_iddeduplication against the browser pixel, with no server for you to run. - The Gateway does not improve Event Match Quality over an app. Both send the hashed customer record server-side; match quality comes from the data you pass, not from who hosts the send.
- Hosting the Gateway yourself pays off in a narrow case: an in-house infrastructure team, a single-cloud or data-residency mandate, or multiple data sources beyond one Shopify store pointing at one gateway.
- If none of those describe you, the operational cost of owning a server outweighs the control, and an app or the native channel sends the identical event.
What is Meta's Conversions API Gateway, exactly?
The Conversions API Gateway is software Meta publishes that you run yourself. You deploy it into a non-Meta cloud account, and Meta supports AWS EKS, AWS ECS Express, and Google Cloud [1]. It has two parts: a middleware service that receives your browser events, transforms them into Conversions API calls, and sends them to Meta, and an admin portal, a web interface for administering and monitoring the instance [1].
The important word is "yourself." Meta provides the image and a setup wizard, but the running instance lives in your cloud account, in a region you choose, on infrastructure you pay for. When Meta ships an update, the Gateway can apply it automatically, but only with the host admin's consent [1]. That is a different arrangement from a hosted service, where the vendor owns and patches everything, and different again from the native Shopify channel, where Shopify hosts the integration.
This is also where the Gateway gets confused with two other things. It is not a Google Tag Manager server container, which is Google's middleware for the same job, and running an sGTM container is its own project, covered in what a server-side GTM container is on Shopify. The Gateway is Meta's equivalent, dedicated to Meta. And it is not a Shopify app, which is the confusion worth clearing up next.
Is the Gateway just another Shopify app?
No. This is the single most common misread, and it changes the whole decision. A merchant sees "Meta's official Conversions API tool, and the software is free" and pictures an App Store install: click add, authorize, done. The Gateway is not that. There is no Shopify listing. You start it from Meta's Events Manager, and the setup deploys an AWS CloudFormation stack into your own AWS account, which takes about 30 to 40 minutes just to create the resources before you begin configuration [2].
After that, the instance is a server you operate. It has a region, a security posture, a cloud bill, and a lifecycle. A Shopify app inverts all of that: you install it from the App Store, connect it through the Shopify Admin, and the vendor runs the middleware on their infrastructure. The comparison below puts the three paths side by side.
| Dimension | Meta CAPI Gateway | Shopify tracking app | Native Facebook & Instagram channel |
|---|---|---|---|
| Who hosts it | You, in your AWS or GCP account | The app vendor | Shopify |
| Setup | CloudFormation stack, ~30 to 40 min to create [2] | App Store install, then Admin connect | Add sales channel |
| Ongoing cost | Your cloud resources or partner fees [1] | App subscription | Included |
| Ops burden (patching, uptime, region) | Yours | Vendor's | Shopify's |
| Server-side Purchase (CAPI) | Yes | Yes | Yes |
| event_id deduplication | Yes, you configure it | Yes, handled for you | Yes |
| Best fit | Infra team, data-residency, multi-source | A single store wanting server-side with nothing to host | A store wanting Meta's baseline, no add-ons |
What does running the Gateway actually cost you?
Meta's own documentation is precise on the money: the only cost associated with the Gateway is the cloud resource or partner fees [1]. Meta charges nothing for the software, and your bill is whatever AWS or Google Cloud charges to run it. That number is small for a single store, but it is not zero, and more to the point, it is yours. You are now the account that receives the invoice and the account that has to reason about right-sizing the instance.
The cash cost is the easy part. The real cost is operational. You own patching when Meta ships an update, uptime when the instance has a problem, the region decision with its latency and compliance implications, and the security of a service that handles hashed customer data. None of that is exotic for a team that runs cloud infrastructure already. For a marketing team without one, it is a new on-call surface for a job a subscription can absorb entirely. The useful way to frame the choice is not "more control." It is who gets paged when the middleware breaks.
How a tracking app sends the same server-side CAPI without a server
A Shopify tracking app reaches the same endpoint the Gateway does, Meta's Conversions API, from the vendor's servers. WeltPixel Conversion Tracking sends the Purchase server-side from Shopify's orders/create webhook, so the conversion fires from Shopify's confirmed order rather than the shopper's browser. That is what makes it survive ad blockers, iOS restrictions, and abandoned browser sessions, the same durability the Gateway is bought for. Why you want both the browser and server sends is covered in Conversion API vs browser pixel.
Two details matter for parity. First, deduplication: the server-side Purchase and the browser Purchase carry the same event_id, so Meta collapses them into one conversion instead of counting two. That is the mechanism in how event_id prevents double counting, and a tracking app wires it for you. Second, match quality: the server-side Purchase carries the hashed customer record, email, phone, name, and address components, plus the Meta browser identifiers and the customer IP, which is what feeds Event Match Quality. A Gateway sends the same category of data. Neither path has a match-quality edge over the other by virtue of who hosts it; match quality comes from the completeness of the data you pass, covered in the Event Match Quality guide.
When does hosting the Gateway yourself genuinely pay off?
The Gateway is the right call in a small number of situations, and they are nameable. The first is an in-house infrastructure or data team. If you already run cloud services and have people who patch and monitor them, absorbing one more instance is cheap, and owning the pipe has real appeal. The second is a data-residency or single-cloud mandate. If policy requires event middleware to run inside your own cloud boundary or a specific region, a vendor-hosted app cannot satisfy that and the Gateway can. The third is multiple data sources. If you have several storefronts or non-Shopify properties that should feed one Meta pipeline, a self-hosted gateway can sit in front of all of them.
Outside those, the math tilts the other way. A single Shopify store running standard commerce events at normal Meta spend gets the identical server-side Purchase from an app or the native channel, with event_id dedup and the hashed customer record, and nothing to host. Spending engineering time to own a server for that is cost without a matching return.
Where does the native Facebook & Instagram channel fit?
Before either the Gateway or an app, there is Shopify's native Facebook & Instagram sales channel, which sends server-side events through Shopify's own hosted integration. It is the baseline, and for some stores it is enough. The trade-offs between that native channel, a GTM server container, and an app are the subject of a separate comparison: Meta CAPI on Shopify, native channel vs GTM vs app. This article sits one level deeper on the do-it-yourself end of that spectrum, because the Gateway is the option people reach for once they have decided they want to run Meta's middleware themselves rather than hand it to Shopify or a vendor.
FAQ
Is the Meta Conversions API Gateway free?
The software is free from Meta, but running it is not. Meta's documentation states the only cost is your cloud resources or partner fees, which means you pay AWS or Google Cloud to host the instance [1]. That bill and the instance's upkeep are yours to manage.
Is the Gateway hosted by Meta?
No. You deploy it into your own AWS or GCP account, and Meta supports AWS EKS, AWS ECS Express, and Google Cloud [1]. Meta provides the software and updates, but the running server lives in your cloud account, in a region you pick.
Does the Gateway get better Event Match Quality than a tracking app?
No. Both send the hashed customer record to Meta's Conversions API server-side. Match quality depends on how complete that data is, not on who hosts the send. An app that passes email, phone, name, address, and the customer IP reaches the same quality ceiling.
Do I still need the browser pixel if I use the Gateway or an app?
Yes. Meta recommends sending both the browser event and the server event, deduplicated by a shared event_id, so you capture conversions the browser misses without double counting. Sending server-side only leaves signal on the table.
Is the Gateway worth it for a single Shopify store?
Usually not. A single store at normal Meta spend gets the same server-side Purchase with dedup from an app or the native channel, without operating a server. The Gateway starts to make sense when you have an infrastructure team, a data-residency rule, or multiple properties feeding one pipeline.
Send server-side Meta conversions without running a server
If you want reliable server-side Meta conversions but do not want to own a CloudFormation stack, that is exactly the gap a tracking app fills. WeltPixel Conversion Tracking sends the Purchase to Meta server-side from Shopify's order webhook, deduplicated against the browser pixel by event_id, with the hashed customer record and IP for Event Match Quality, and it connects through the Shopify Admin instead of your cloud account. You can add it from the App Store: https://apps.shopify.com/weltpixel-conversion-tracking?utm_source=blog&utm_campaign=072
Sources
- Meta for Developers, "Conversions API Gateway" (overview). https://developers.facebook.com/docs/marketing-api/gateway-products/conversions-api-gateway (accessed 2026-07-06).
- Meta for Developers, "Conversions API Gateway: Setup Guide." https://developers.facebook.com/docs/marketing-api/gateway-products/conversions-api-gateway/setup (accessed 2026-07-06).
- Meta Business Help Centre, "About Conversions API gateway." https://www.facebook.com/business/help/387152639648383 (accessed 2026-07-06).
- Meta for Developers, "Conversions API." https://developers.facebook.com/docs/marketing-api/conversions-api (accessed 2026-07-06).
- Shopify Developers, "Web Pixels API." https://shopify.dev/docs/api/web-pixels-api (accessed 2026-07-06).