Meta CAPI Through Server-Side GTM
We run your Meta Conversions API from a server-side GTM container you own. Events reach your first-party endpoint, the Meta CAPI tag builds each request, and you control exactly which fields leave your server. For teams that already use sGTM or want Meta on the same infrastructure.
Why Plugin-Based CAPI Leaves You Without Control
Many sites send Conversions API events through a platform plugin or partner integration. It works, but the data path is opaque and hard to extend.
- 01
No Visibility Into Payloads
Built-in integrations decide which fields go to Meta, and you cannot easily inspect or change the request before it is sent.
- 02
Separate Pipelines per Vendor
Meta runs through one integration and Google through another, so each platform receives slightly different event data.
- 03
Limited Routing Rules
There is no single place to drop a parameter, block an event for a region or enrich a purchase before Meta sees it.
What We Build for Meta Inside sGTM
The Meta side runs as one more tag in your server container. It reuses the same incoming event stream as GA4 and Google Ads, with rules specific to Meta.
- 01
Meta CAPI Server Tag
A Conversions API tag template configured with your pixel ID and a system user access token stored in the container.
- 02
Shared Event Stream
Meta events built from the same GA4-format stream the server already receives, with event names mapped to Meta standard events.
- 03
First-Party Endpoint
Browser data arrives at your own subdomain, so _fbp and _fbc values can be read and kept as first-party cookies.
- 04
User Data Routing
Rules that choose which hashed fields, such as em and ph, are sent to Meta and which are held back.
- 05
Event ID for Deduplication
A shared event_id passed from the web container so Meta can match server events to any remaining Pixel events.
- 06
Consent and Region Filters
Triggers that block or limit Meta requests based on consent state or visitor region before any call is made.
How Meta Events Travel Through Your Server
One browser event reaches your endpoint, and the server container decides what version of it Meta receives.
- 01Browser EventPurchase or lead captured by web GTM
- 02Your EndpointSent to sGTM on your subdomain
- 03Routing RulesConsent, region and field filters
- 04Meta CAPI TagBuilds the Conversions API request
- 05Events ManagerServer event received and deduplicated
From audit to validated data.
How Meta CAPI projects run. Nothing goes live until it has been tested.
- 01
Audit
Audit current Meta integrations, sGTM setup and which events reach Events Manager
- 02
Strategy
Plan event mapping, user data fields and which requests move off plugins
- 03
Implementation
Install the Meta CAPI tag in sGTM and wire it to the shared event stream
- 04
Testing
Test payloads in server preview and Meta's Test Events tool
- 05
Validation
Validate deduplication and event coverage, then document the routing rules
What's Included in Meta CAPI
Everything is documented and handed over, so your team knows exactly what was built and why.
- 01
Meta Tag Configuration
Conversions API tag, triggers and event mapping set up and published in your server container.
- 02
Hosting Review
Your existing sGTM hosting checked, or a new Cloud Run or Stape setup planned if none exists yet.
- 03
Data Routing Map
A diagram of which fields flow to Meta, which are hashed and which are removed before sending.
- 04
Events Manager QA
Test events checked in Meta's Test Events tool, with deduplication and parameter coverage reviewed.
- 05
Token and Access Setup
Access token generated under a system user and stored in the container, not in page code.
- 06
Setup Documentation
Written notes on the tag template, variables, triggers and how to add new Meta events later.
Platforms
The tools involved in a typical Meta CAPI implementation.
- Meta Events ManagerServer events and testing
- Server-Side GTMMeta CAPI tag
- Web GTMEvent and ID capture
- StapeManaged sGTM hosting
- Google Cloud RunSelf-managed hosting
Tested before anything goes live.
Test payloads in server preview and Meta's Test Events tool. Validate deduplication and event coverage, then document the routing rules.
- sGTM PreviewIncoming requests claimed by the right clientchecked
- Outgoing requestsEach vendor request checked for payload and statuschecked
- First-party checksEndpoint and cookies served from your own subdomainchecked
- Platform debugGA4 DebugView, Google Ads diagnostics and Meta Test Eventschecked
Each check is repeated after launch on live traffic.
How is this different from your Meta Conversions API service?
Our Meta Conversions API service covers CAPI in general, including partner and platform integrations. This page is specifically about running CAPI as a tag inside your own server-side GTM container, sharing infrastructure and data with GA4 and Google Ads.
Do I need an existing sGTM container?
No. If you do not have one, we set it up as part of the project. If you already run sGTM for GA4 or Google Ads, the Meta tag is added to that container and reuses its hosting and endpoint.
Should I remove the Meta Pixel after adding CAPI?
Usually not. Meta recommends running Pixel and Conversions API together with a shared event_id for deduplication. We keep the Pixel where it adds value and make sure both sources are matched correctly.
Which tag template do you use for Meta in sGTM?
We use a maintained Conversions API template from the GTM community gallery or the one provided by your hosting partner, reviewed before install. The choice is documented so your team knows what to update later.
Can I control which customer data Meta receives?
Yes. That is one of the main reasons to route CAPI through your own server. Every user data field is an explicit choice in the tag, so you can send hashed email only, add phone, or send no personal data at all.
Get Meta CAPI right the first time.
Build a tracking and measurement system you can trust.
Get Free Tracking Audit Talk to GrowthUper Free 30-minute review · No obligation