Short answer
A Meta Conversions API setup sends conversion events from your server to Meta alongside the browser pixel. You choose an integration method (partner integration, Conversions API Gateway, server-side GTM or direct API), send each event with hashed customer information, deduplicate it against the pixel with a shared event_id, and verify it in Events Manager.
What is a Meta Conversions API setup?
A Meta Conversions API setup is the plumbing that lets your server tell Meta about purchases, leads and other events directly, so Meta can match them to people and optimise delivery even when the browser pixel is blocked or limited.
The Conversions API (CAPI) is Meta's server-to-server endpoint for the same events the Meta Pixel sends from the browser. Meta's documentation describes it as a complement, not a replacement: it expects the same Pixel ID for browser and server events, and it deduplicates the two when they describe the same action (Meta for Developers). The reasons to add it are the ones every advertiser now knows: ad blockers (912 million active ad-blocking users by Q2 2023, according to the eyeo and Blockthrough report), browser cookie limits such as WebKit's 7-day cap on script-written cookies, and journeys where the browser never reaches the page that fires the pixel.
The principles behind running both are covered in Meta CAPI vs pixel tracking. This page is the build guide: it covers every platform, not just Shopify (which has its own guide on Shopify server-side tracking), and it goes deeper into the payload, deduplication and verification than the general overview.
Meta ad reach in India, late 2025 (users)
The audience behind those signals is large in both markets this page serves. DataReportal's Digital 2026 reports put Meta's late-2025 ad reach at 403 million on Facebook and 481 million on Instagram in India, and 198 million and 182 million in the United States (DataReportal). When the delivery system can match more of your conversions to those people, it has more examples to learn from; that is the whole commercial case for a careful Meta CAPI integration.
Which Conversions API integration method should you use?
Use a partner integration if your platform has a good one, the Conversions API Gateway if Meta is your main channel and you have no developer, server-side GTM if several platforms need the same events, and a direct API build when events come from a backend or CRM.
| Method | How it works | Best for | Watch out for |
|---|---|---|---|
| Partner integration | Your platform (Shopify, WooCommerce plugins, CRMs, CDPs) sends server events for you | Standard ecommerce and lead flows on a supported platform | Limited control over event definitions; duplicate sends if you also add a custom build |
| Conversions API Gateway | A Meta-built, self-serve server hosted in your own AWS (EKS or ECS Express) or GCP account forwards pixel events | Meta-focused advertisers without developer resources | Meta only; you pay the cloud bill; mirrors pixel events rather than adding backend truth |
| Server-side GTM | A tagging server on your own domain receives browser events and sends them to Meta and other platforms | Several ad platforms, custom event logic, first-party cookies | Needs specialist setup, hosting and monitoring |
| Direct API | Your backend or CRM calls the Conversions API endpoint with an access token | Offline sales, CRM stages, COD confirmation, subscriptions, apps | You own hashing, retries, batching and error handling |
Effort vs control across CAPI methods
The conversions api gateway deserves a precise description, because it is often misunderstood. Meta calls it "a self-serve configuration option in Events Manager" with two modules (middleware that receives browser events and forwards them, and an admin portal), provisioned in a cloud account you own, with no coding needed and the only cost being "the associated cloud resource or partner fees" (Meta for Developers). It improves delivery of the events your pixel already sees. It does not add events your pixel never sees, such as a COD order confirmed by phone two days later or a deal marked won in a CRM. Those need the direct API or a server container fed by backend webhooks.
Facebook Conversions API setup by platform
The right Facebook Conversions API setup depends more on where your conversions are decided than on which website builder you use. Walk the tree for your case.
Pick a CAPI method for your stack
Where does the conversion that matters happen?
See the whole decision tree
Where does the conversion that matters happen?
- Online checkout
Is it Shopify?
- YesStart with Shopify's native integrationMaximum data sharing first; custom server build only if COD, third-party checkout or multi-platform needs justify it.Shopify guide →
- No (WooCommerce, custom)Server-side GTM or a maintained pluginUse a well-maintained plugin for simple stores; server-side GTM when Google Ads and GA4 need the same clean events.
- Yes
- Lead form, then sales
Do you need Meta to optimise for qualified leads, not just form fills?
- YesDirect API from the CRMSend lead stage changes (qualified, won) from the CRM with the lead_id or hashed contact data, so Meta learns which leads become customers.CRM conversion guide →
- Not yetGateway or sGTM for the form eventGet the Lead event reliable and deduplicated first; add CRM stages once volumes justify it.
- Yes
- Offline or in storeDirect API with offline action sourcesSend events with action_source physical_store, phone_call or system_generated within 62 days of the conversion. The old Offline Conversions API is legacy.
What must each server event contain?
Every server event needs four things: event_name, event_time, action_source and user_data. Website events also need event_source_url and client_user_agent, and every event that the pixel also sends needs an event_id.
| Parameter | Status | Rule from Meta's documentation |
|---|---|---|
| event_name | Required | Must match the pixel event name for deduplication |
| event_time | Required | Unix seconds; up to 7 days before sending, otherwise the whole request fails |
| action_source | Required | One of email, website, app, phone_call, chat, physical_store, system_generated, business_messaging, other |
| user_data | Required | At least one customer information parameter, correctly formatted |
| event_source_url | Required for website events | The page URL where the event happened |
| event_id | Recommended | Any unique string; must equal the pixel's eventID for the same action (order or transaction IDs work) |
| opt_out | Optional | If true, the event is used for attribution only, not delivery optimisation |
| data_processing_options | Optional | LDU for Limited Data Use; requires country (and state) codes |
| Key | Field | Hash? | Format before hashing |
|---|---|---|---|
| em | Yes | Trim spaces, lowercase | |
| ph | Phone | Yes | Digits only, no leading zeros, with country code |
| fn / ln | First and last name | Yes | Lowercase, no punctuation; UTF-8 for special characters |
| ct / st / zp / country | City, state, postal code, country | Yes | Lowercase; country as ISO 3166-1 alpha-2 |
| db / ge | Date of birth, gender | Yes | YYYYMMDD; f or m |
| external_id | Your customer or lead ID | Recommended | Same value wherever you send it |
| client_ip_address | IP address | Never | The shopper's real IPv4 or IPv6 address |
| client_user_agent | Browser user agent | No | Required for website events |
| fbc / fbp | Click ID, browser ID | No | From the _fbc and _fbp cookies (fbc can be built from fbclid) |
| lead_id | Meta lead ID | No | For lead ads conversions sent back from a CRM |
Meta's best practices say an event is invalid if its customer information only contains city, country, state, postal code, gender and user agent (or a subset), only date of birth and user agent, only first name and gender, or only last name and gender. Location and demographic fields help only alongside a real identifier such as email, phone, external_id, fbc or fbp (Meta for Developers).
How does event_id deduplication work?
Meta keeps one event when a browser and a server event share the same event_name and event_id and arrive within 48 hours of each other. Everything else about deduplication follows from that rule.
One purchase, two sources, one counted event
- Generate the IDUse the order, transaction or lead ID (or a random ID shared with the server).
- Browser sendsPixel fires Purchase with eventID in the fourth argument of fbq track.
- Server sendsCAPI sends Purchase with the same event_id and event_name.
- Meta comparesWithin 48 hours, matching pairs collapse to one; Meta generally keeps the first received.
- VerifyEvents Manager shows deduplicated server and browser events, not double counts.
Meta also supports a fallback: matching on event_name plus fbp and/or external_id. Its documentation is careful about the limits. This method generally works only when the browser event arrives first, and it does not deduplicate within a single source, so two browser events or two server events are both kept (Meta for Developers). The best-practices page recommends including event_id, external_id and fbp together to reduce double reporting. In practice, event_id on both sides is the rule; the fallback is a safety net.
- Browser uses the order number, server uses the order's internal ID: no match, double count.
- Event names differ by case or wording (Purchase vs purchase, Lead vs SubmitApplication).
- A partner app and a custom build both send Purchase with different IDs.
- Server event sent more than 48 hours after the browser event, for example a delayed COD confirmation that should have suppressed the browser Purchase instead.
- The browser pixel fires twice (theme code plus a tag manager), which no event_id on the server can fix.
Plan your Event Match Quality before you build
Event Match Quality depends on which customer parameters each event carries and how often. Planning that before the build is cheaper than retrofitting it. The planner below turns your parameter plan into an estimated band and a ranked fix list.
Event Match Quality planner
Tick the customer information your server events will carry and how often. The planner estimates a match-strength band, checks Meta's invalid-combination rules and deduplication, and lists the missing parameters in the order worth fixing.
Most events will be hard to match. Add email, phone and the browser identifiers before anything else.
- Phone (ph). Send phone hashed, digits only, with country code (91 for India, 1 for the US).
- Click ID (fbc). Read the _fbc cookie, or build fbc from the fbclid URL parameter, and store it with the order.
- External ID (external_id). Send your customer or lead ID as external_id, the same value in browser and server events.
- First name (fn). Add hashed first name from the order or form.
- Last name (ln). Add hashed last name from the order or form.
- Email (em). Capture email at checkout or form submit and send it hashed (SHA-256, lowercase, trimmed).
This is a planning estimate, not Meta's EMQ score, which only Events Manager can show. Formula: match strength = 10 × Σ(weight × coverage) ÷ Σ(all weights). Heavier weights go to the eight parameters Meta's Omni optimal setup guide lists as most heavily weighted (email, phone, IP address, user agent, fbp, fbc, first name, last name); the exact weights are this tool's assumption because Meta does not publish them. Email and phone count at half weight if they are not normalised before hashing (Meta requires lowercase, trimmed email and phone with country code). The invalid-combination check follows Meta's Conversions API best practices; client_user_agent and event_source_url are required for website events.
Meta defines EMQ as a score out of 10 showing how effective the customer information you send is at matching events to Meta accounts, and it is currently available only for web events (Meta for Developers). Meta's dataset quality documentation adds that it is calculated from which parameters you send, their quality, and the percentage of events matched (Meta for Developers). Its Omni optimal setup guide names the most heavily weighted customer parameters: email, phone number, IP address, user agent, fbp, fbc, first name and last name (Meta for Developers). What scores to aim for, and where the missing fields usually hide, is covered in Meta Event Match Quality explained.
Meta CAPI integration for lead gen, CRMs and offline sales
For lead-gen and offline businesses, a Meta CAPI integration matters more than for ecommerce, because the conversion that matters (a qualified lead, a closed deal, a store visit) never happens in the browser.
Meta now routes offline events through the Conversions API itself: its offline conversions documentation calls the Conversions API "Meta's recommended integration method for sending offline and physical store events" and refers to the Offline Conversions API as "Meta's legacy API for offline events" (Meta for Developers). The action_source field tells Meta where the event happened (phone_call, chat, physical_store, system_generated and others), and offline and physical store events should be uploaded within 62 days of the conversion (Meta for Developers).
For lead ads, the CRM side is where the value is. When a lead changes stage in HubSpot, Zoho or Salesforce, a server event carrying the lead_id (or hashed email and phone) tells Meta which leads became qualified or won, so delivery can shift toward people who resemble buyers rather than form-fillers. The equivalent Google side is in enhanced conversions for leads with HubSpot and Zoho, and WhatsApp-originated leads are covered in tracking WhatsApp leads as offline conversions. If CRM stages themselves are unreliable, fix them first: a HubSpot portal audit usually finds why lifecycle stages cannot be trusted as signals.
For COD ecommerce the same principle applies: the server sends Purchase when the order is confirmed, not when it is placed, within the 7-day event_time limit. The full event plan is in Meta CAPI for Shopify COD orders.
- Event fires in the browser on submit
- Every submission counts the same
- Meta finds people who fill forms
- Spam and low-intent leads look like wins
- Easy to set up
- Event sent from the CRM by server
- Only qualified or won leads count
- Meta finds people who resemble buyers
- Junk leads stop teaching the algorithm
- Needs clean stages and a lead or contact ID
How to test a Conversions API setup and prove it works
Test with test_event_code before launch, then judge the live setup on four signals Meta reports: event match quality, event coverage, deduplication key coverage and data freshness. Volume going up is not proof on its own.
Before launch. Generate a test code in Events Manager (Data Sources, your pixel, Test Events) and pass it as test_event_code; Meta says events should appear within 20 minutes, and the code must be removed from production payloads (Meta for Developers). Run one journey per conversion path, and per payment method for ecommerce.
After launch. Meta's dataset quality metrics give you a scorecard. Event coverage is "the 7-day average percentage of Meta Pixel events that are covered by the Conversions API", and Meta uses coverage below 75% as the threshold for its coverage-related additional conversions estimate. Deduplication key feedback shows the share of browser and server events carrying event_id, external_id or fbp. Data freshness shows the delay between the event and Meta receiving it; Meta recommends real time or as close as possible. Additional Conversions Reported (ACR) estimates how much the Conversions API adds, including the potential gain from sending more or better match keys (Meta for Developers).
Conversions API launch checklist
Hashing, consent and Limited Data Use
Server events still carry personal data, so a CAPI setup needs the same consent logic as the pixel, hashing for identifiers that require it, and documented choices for regulated markets.
- Hash what Meta says to hash: email, phone, names, date of birth, gender and address fields are SHA-256 hashed after normalisation. IP address and user agent must not be hashed.
- Pass consent to the server: if a visitor declines marketing cookies, the server event for that visitor should not be sent (or should follow your documented legal basis). Server-side is not a consent workaround.
- Use opt_out where appropriate: Meta lets you mark an event for attribution only, so it is not used for delivery optimisation.
- Limited Data Use: for US states where it applies, data_processing_options with LDU, plus country and state codes, limits how Meta processes the event. Decide this with counsel.
- India: Hogan Lovells reports the DPDP Rules were notified on 13 November 2025, with notice and consent obligations applying from 13 May 2027. Build the consent check into the server path now; the banner side is covered in Consent Mode v2 and the DPDP Act.
- Apple platforms: in iOS 14.5 and later, apps must ask permission through App Tracking Transparency before tracking users across other companies' apps and websites, which is one reason website and server signals carry more weight.
Who does what in a CAPI setup, and how long it takes
A Conversions API setup touches marketing, engineering and sometimes legal. Agreeing who owns each step avoids the most common failure: a setup nobody maintains.
Responsibilities across a Meta CAPI setup
- Week 1Audit and plan
Inventory every pixel and partner integration, baseline platform vs backend counts, choose the method and parameter plan.
- Weeks 2–3Build
Payloads, hashing, event_id, consent checks; Gateway deployment or server container if chosen.
- Week 3Test
test_event_code journeys for every conversion path; fix formatting and deduplication.
- Weeks 4–6Watch
Live diagnostics weekly; compare with backend; expect campaigns optimising on changed events to re-enter learning.
- MonthlyMaintain
API version changes, new checkout or CRM fields, new events; re-check coverage and deduplication.
Meta conversions API setup service: cost, scope and red flags
A Meta conversions API setup service is usually priced by scope (number of events, sources and platforms), plus your own hosting where a Gateway or server container is used. The cheapest setups are the ones that end up re-done.
Costs fall into three lines. Build: from a short configuration of a partner integration to a multi-week direct API or server-side GTM project with CRM and COD logic. Hosting: none for partner integrations; cloud fees for the Gateway (Meta's only stated cost) or a server container. Ownership: someone has to watch diagnostics and update the setup when Meta's API versions or your checkout change. What a complete deliverable looks like, from deduplication to documentation, is set out in what a server-side CAPI setup service includes.
Rahul handles CAPI work as part of Meta Ads management when the media and signal need fixing together, or within the analytics and attribution service when Meta is one of several platforms. Where it is not yet clear whether tracking is the real problem, the fixed-price Revenue Diagnostic reviews ad accounts, analytics and CRM over two weeks first. Real results from this work are documented: in the D2C FMCG case study, pixel match rate went from 31% to 74% within two weeks of CAPI launch, and in the B2B SaaS case study signal loss fell from 38% to 6% within three weeks.
- Supported platform with a good partner integration
- Meta is the only channel and the Gateway fits
- You have a developer who can read Meta's docs
- Simple prepaid checkout or a single lead form
- Someone will check diagnostics weekly
- COD, CRM stages or offline sales need custom events
- Several platforms need the same clean events
- Duplicates or low EMQ you cannot explain
- No in-house tracking owner
- Large spend riding on the signal
- Claims of a guaranteed EMQ score or ROAS uplift.
- No mention of event_id or how browser and server events will be deduplicated.
- Setup that sends server events regardless of the visitor's consent.
- No test plan, no before-and-after comparison with backend data.
- Access tokens or customer data handled in shared documents.
- No documentation, so the setup leaves with the provider.
Myth The Conversions API replaces the pixel.
Reality Meta expects the same Pixel ID for both and deduplicates them. Running both, deduplicated, is the documented setup.
Myth Higher EMQ always means better results.
Reality EMQ measures how matchable your events are. It helps delivery only if the events themselves are right; a well-matched wrong conversion still teaches the wrong lesson. Creative remains the main lever, as Advantage+ creative testing shows.
Myth The Gateway sends offline and CRM events.
Reality It forwards events your pixel sees. Offline, CRM and delayed confirmation events need the direct API or a server container fed by backend data.
Request a Meta Conversions API setup
Tell me what you sell, where conversions happen and how Meta tracking works today. You will get a reply recommending a method and scope.
Tell me about your Meta tracking
A few details about your platform, conversion paths and current setup are enough to recommend partner, Gateway, server-side GTM or direct API.
Meta Conversions API setup: common questions
Do I still need the Meta Pixel if I set up the Conversions API?
Yes. Meta's documentation expects the same Pixel ID for browser and server events and deduplicates them when they share event_name and event_id. The pixel captures browser context and early-funnel events cheaply; the server path adds reliability and backend truth.
What is the Conversions API Gateway?
It is a self-serve option in Events Manager that deploys Meta-built middleware into a cloud account you own (AWS EKS, AWS ECS Express or GCP) and forwards pixel events to the Conversions API. No coding is needed and the only cost is the cloud resources or partner fees. It suits Meta-focused advertisers without developers, but it does not add offline or CRM events.
How does Meta deduplicate pixel and server events?
When a browser and a server event share the same event_name and event_id and arrive within 48 hours, Meta keeps one, generally the first received. A fallback using fbp or external_id works mainly when the browser event arrives first and never deduplicates within one source.
How far back can I send Conversions API events?
Website and other events can have an event_time up to 7 days before you send them; if any event in a request is older, Meta rejects the whole request. Offline and physical store events should be uploaded within 62 days of the conversion.
Which customer parameters improve Event Match Quality the most?
Meta's Omni optimal setup guide lists email, phone number, IP address, user agent, fbp, fbc, first name and last name as the most heavily weighted. Sending them on a high share of events, correctly normalised and hashed where required, matters more than adding rare fields such as date of birth.
Should IP address and user agent be hashed?
No. Meta says client_ip_address must never be hashed and client_user_agent is sent as the raw browser string; client_user_agent is required for website events. Email, phone, names and address fields are the ones to normalise and hash with SHA-256.
Can I send CRM or offline sales to Meta?
Yes, through the Conversions API with the right action_source (for example system_generated, phone_call or physical_store) and customer information or a lead_id. Meta describes the Conversions API as its recommended method for offline events and treats the older Offline Conversions API as legacy.
How do I know my CAPI setup is working?
Use test_event_code before launch, then check Events Manager: deduplicated browser and server events, EMQ for key web events, event coverage above 75%, deduplication keys on most events and near real-time freshness. Finally, compare Meta-reported conversions with your backend for a few weeks.
Why did my reported conversions jump after adding CAPI?
Either the server is recovering events the pixel was missing, or the same conversions are being counted twice. Check deduplication indicators and compare with backend orders or CRM leads; if Meta now reports more conversions than actually happened, deduplication is broken.
How long does a Meta Conversions API setup take?
A partner integration or the Gateway can be live in a day. A server-side GTM or direct API build with CRM stages, COD logic and testing typically takes three to six weeks including a monitoring period, and longer if the conversion definitions themselves need agreeing first.
Sources
- Get started with the Conversions API, Meta for Developers. Accessed 2026-10-15.
- Using the Conversions API, Meta for Developers. Accessed 2026-10-15.
- Server event parameters, Meta for Developers. Accessed 2026-10-15.
- Customer information parameters, Meta for Developers. Accessed 2026-10-15.
- Handling duplicate Pixel and Conversions API events, Meta for Developers. Accessed 2026-10-15.
- Conversions API best practices, Meta for Developers. Accessed 2026-10-15.
- Conversions API Gateway, Meta for Developers. Accessed 2026-10-15.
- Dataset Quality API, Meta for Developers. Accessed 2026-10-15.
- Omni optimal technical setup guide, Meta for Developers. Accessed 2026-10-15.
- Offline conversions, Meta for Developers. Accessed 2026-10-15.
- Digital 2026: India, DataReportal (Kepios). Accessed 2026-10-15.
- Digital 2026: The United States of America, DataReportal (Kepios). Accessed 2026-10-15.
- 2023 eyeo Ad-Filtering Report, Blockthrough (eyeo). Accessed 2026-10-15.
- Tracking Prevention in WebKit, WebKit. Accessed 2026-10-15.
- User privacy and data use, Apple Developer. Accessed 2026-10-15.
- Meta data sharing, Shopify Help Center. Accessed 2026-10-15.
- Map server-side tagging to a custom domain, Google for Developers. Accessed 2026-10-15.
- India's Digital Personal Data Protection Act 2023 brought into force, Hogan Lovells. Accessed 2026-10-15.