What is the Meta Conversions API?
The Meta Conversions API is an interface that lets your server send events, such as a purchase, lead or registration, directly to Meta, instead of relying only on the Pixel running in the visitor’s browser. It feeds the same dataset the Pixel uses.
The Pixel is a piece of JavaScript on your pages. It sees what happens in the browser and reports it to Meta, which works well until something gets in the way: an ad blocker, a browser that restricts third-party scripts or cookies, a visitor who leaves before the thank-you page loads, or a payment that completes on another domain and never returns. Each of those is a conversion your ads caused that Meta never hears about.
The Conversions API closes that gap by sending the event from the place where it is certain to be known, your server, your store platform or your CRM. Meta recommends using both together: the Pixel for browser context and quick signals, the Conversions API for reliability, with deduplication so the same conversion is not counted twice.
- Browser events: sent by the Pixel from the visitor’s device
- Server events: sent by your backend, store or CRM through the Conversions API
- Dataset: where Meta combines both streams for reporting and optimisation
- Deduplication: matching event_name and event_id so each action counts once
When do you need a Meta Conversions API setup?
You need it when the purchases or leads Meta reports are clearly fewer than your real orders or enquiries, when your checkout or booking finishes somewhere the Pixel cannot see, or when valuable conversions happen offline or on WhatsApp.
A simple test: pick a week, count orders or qualified leads in your own system, then compare with conversions attributed in Ads Manager for the same period. Some gap is normal, because not every sale comes from an ad. A very large gap, or reported purchases that are higher than real orders, points to tracking problems, usually missing server events or broken deduplication.
Businesses that benefit most include ecommerce stores spending meaningfully on Meta ads, lead-generation businesses whose real conversion happens days later on a call, clinics and coaching institutes that close enquiries on WhatsApp, and stores with both online and in-shop sales. If you spend very little on Meta ads, a clean Pixel setup might be enough for now.
Strong signs you need it
Big gap between Meta’s numbers and real orders; off-site payment pages; conversions on calls, in-store or on WhatsApp; custom checkout or booking code.
Signs it can wait
Very small ad spend, a standard store checkout already covered by the platform’s own integration, and no offline sales.
Planning events before any Meta Conversions API setup
Start with a written event plan: which actions matter, what each event is called, which parameters it carries, and whether it is sent from the browser, the server, or both. Without it, setups drift into double counting and mismatched names.
For a store, the core list is usually ViewContent, AddToCart, InitiateCheckout and Purchase, with value, currency and content IDs matching your product catalogue. For lead generation, it is Lead at form submission, then custom or standard events for later stages such as a qualified lead or a booked appointment. Names must match character for character between browser and server; Meta treats “Purchase” and “purchase” as different events.
We also mark where the event is truly confirmed. A Purchase should fire when payment succeeds, not when the “Place order” button is clicked. A Lead should fire when the form is accepted by your backend, not when the page with the form loads. Getting those moments right matters more than any amount of match-quality tuning.
Meta Conversions API setup on Shopify
On Shopify, the usual route is Meta’s official Facebook and Instagram sales channel app, which connects your store to your Pixel and can share server-side events. Our job is to configure it correctly, confirm it is the only source of those events, and verify deduplication and match quality.
The most common problem on Shopify stores is duplicate tracking: the official app sends events, a theme still contains an old hard-coded Pixel, and a third-party tracking app sends its own server events too. Events Manager then shows inflated purchases. We audit the theme code, custom pixels and installed apps, remove the extras, and leave one clean path.
Shopify’s own integration covers the standard storefront and checkout. Custom additions, such as a separate booking flow, a subscription app with its own checkout, or orders taken on WhatsApp and entered manually, may need additional server events sent from an app or a small cloud function. That is where our Shopify work overlaps with Shopify WhatsApp integration.
Meta Conversions API setup on WordPress and WooCommerce
On WordPress and WooCommerce, Meta’s official plugin can send Pixel and server events for standard shop actions. A custom setup makes sense when you use page builders, custom forms, membership plugins or a checkout the plugin does not understand.
We check which plugins already inject the Pixel. It is common to find the official plugin, a marketing plugin and a tag manager container all firing PageView and Purchase, which leads to duplicates or conflicting event names. We choose one path for each event and remove the rest.
For lead-generation sites built on WordPress, the key event is the form submission. We hook into the form plugin’s server-side submission action to send the Lead event through the Conversions API with the same event_id that the browser Pixel receives on the thank-you step. Hashed email and phone from the form improve matching, and the event fires only if the form actually saved, not on failed validation.
For store builds and fixes, see WooCommerce development; for tag containers, Google Tag Manager setup.
Server events from a custom backend or booking system
If your checkout, booking engine or lead form runs on your own code, the cleanest Meta Conversions API setup sends events straight from that backend at the moment the action is confirmed. We add a small module that builds the event, hashes customer data and posts it to Meta’s events endpoint.
Meta’s documentation allows up to 1,000 events in one request and recommends sending events promptly, ideally within an hour; it also notes that if any event in a batch is invalid, the whole batch is rejected. So we send real-time events individually or in small batches through a queue, validate them before sending, and log every response so a rejected event is visible, not silent.
The event_time can be up to seven days before you send it, according to Meta’s server event parameter reference, which gives room to retry after an outage. We store unsent events and retry with backoff. The access token lives in your server’s secret store, never in front-end code, and is generated from your Business Manager so it survives staff changes.
- Node.js, PHP (Laravel), Python (Django, FastAPI) and serverless functions supported
- Events queued and retried, with a dead-letter log for anything Meta rejects
- Access token stored as a server secret, rotated if exposed
- test_event_code used in staging only, removed for production
How event ID deduplication works in a Meta Conversions API setup
Deduplication means Meta keeps one copy of an action that both the Pixel and the server reported. Meta’s documentation says it matches browser and server events by event_name and event_id, and deduplicates them if they are received within 48 hours of the first event with that ID.
The practical rule is simple: generate one unique ID per action, for example the order number or a random ID created when the form is submitted, and send exactly that string with both the Pixel call (as eventID) and the server call (as event_id). IDs must be unique per occurrence; reusing a fixed ID for every purchase would make Meta drop real conversions.
Meta also describes an alternative that uses event_name with fbp and/or external_id, but notes it only works when the browser event arrives first and the server event later. We use event IDs as the primary method and pass fbp and external_id as well, because they help matching. After launch, we check Events Manager’s deduplication view for each event and fix any event where browser and server copies are not merging.
Event Match Quality: sending customer data that helps Meta match
Event Match Quality is Meta’s rating, shown in Events Manager, of how well the customer information on your server events lets Meta connect them to the people who saw your ads. More reliable identifiers, sent correctly, mean more conversions attributed to the right ads.
The strongest identifiers are email and phone number. Meta’s customer information parameter reference requires them to be normalised and hashed with SHA-256 before sending: emails trimmed and lowercased; phone numbers stripped of symbols and leading zeros and always including the country code, so an Indian mobile is sent with 91 in front. Name, city, state, postcode and country are hashed too.
Some parameters must not be hashed: the client IP address, the browser user agent, and the fbc and fbp cookie values. The fbc value carries the click ID from the ad; we capture it from the landing URL or cookie and pass it through to the server event, even when the conversion happens later. Adding an external ID, such as your own customer ID hashed, helps connect repeat actions by the same customer.
Offline, phone and CRM conversions through the Conversions API
Conversions that happen away from your website, in a store, over the phone or in your CRM days later, can be sent to Meta through the same Conversions API, marked with an action_source that says where they happened. Meta’s parameter reference lists values including physical_store, phone_call, email, chat, system_generated and business_messaging.
For lead-generation businesses, this is often the most valuable part of a Meta Conversions API setup. When a salesperson marks a lead as qualified or converted in the CRM, that stage is sent to Meta with the lead’s identifiers, so campaigns can optimise toward leads that become customers. Meta’s guidance for CRM lead integrations recommends uploading data at least once a day.
For stores with walk-in sales, a daily export from the billing software, with hashed phone numbers or emails collected at the counter with consent, can be sent as offline purchases. Match rates are lower than online, since not every walk-in customer shares contact details, but they give a far truer picture of what Meta ads contribute.
If your leads come from instant forms, the CRM side is covered on Facebook lead ads CRM integration.
Tracking WhatsApp lead and sales conversions from click-to-WhatsApp ads
If your ads open a WhatsApp chat instead of a website, the Pixel sees nothing after the click. The Conversions API for business messaging lets you report what happens in the chat, such as a lead submitted or an order placed, back to Meta.
Meta’s documentation for these events uses action_source set to business_messaging and messaging_channel set to whatsapp, with the WhatsApp Business Account ID and the ctwa_clid, the click ID Meta passes to your business when a chat starts from a click-to-WhatsApp ad. Supported events include LeadSubmitted, QualifiedLead, Purchase and OrderCreated, and Meta notes that these events should represent interactions that occur in the messaging thread itself.
To send them, your WhatsApp setup must capture the ctwa_clid when the conversation starts and keep it with the chat. We build that into your WhatsApp Business Platform integration or inbox, then send events when an agent tags a chat as a lead or confirms an order. Businesses that sell mostly through WhatsApp finally see which ads produced orders.
Consent and privacy in a Meta Conversions API setup
Server-side tracking does not remove the need for consent. It should follow the same choices the visitor made in the browser, and personal data should be hashed before it leaves your server.
India’s Digital Personal Data Protection Act, 2023 governs personal data such as email addresses and phone numbers, and the Ministry of Electronics and Information Technology notified the DPDP Rules on 13 November 2025, with most obligations phased in over 18 months. If you sell to other countries, their rules may apply too. We are developers, not lawyers: your own adviser should confirm what your notices and consent flows need to say. What we build supports those decisions.
In practice, that means the server path reads the same consent state as your banner or form, and skips or reduces events when consent is not given. Customer data is hashed with SHA-256 as Meta requires, only the fields in the event plan are sent, and access tokens stay on the server. For visitors in the United States, Meta’s documentation describes Limited Data Use options passed with each event, which we can include if your adviser recommends it.
- Server events follow the consent captured in the browser or form
- Only fields listed in the event plan are sent
- Email, phone and name hashed with SHA-256 before sending
- Access tokens kept server-side and owned by your Business Manager
- Privacy notice updated by you to mention Meta measurement
Conversions API Gateway, server-side tagging or direct integration?
There are three main routes to a working Conversions API: an official platform integration (Shopify, WooCommerce and others), Meta’s Conversions API Gateway or a server-side tag container, and direct calls from your own backend. Pick based on where your conversions are confirmed.
Platform integrations are the fastest for standard stores. The Conversions API Gateway and server-side tag containers mirror browser events to the server without much backend code, which suits sites where a developer cannot easily touch the application. They need hosting on a cloud account in your name and some ongoing care.
Direct backend integration is the most precise, because the event fires from the code that confirms the payment or saves the lead, and it can include data the browser never sees. It needs a developer for changes. Many of our setups combine routes: platform integration for the store, direct calls for a custom booking form, and CRM uploads for offline outcomes.
How to test a Meta Conversions API setup before trusting the numbers
Test with Events Manager’s Test Events tool first, then watch production data for a week before judging campaigns on it. Meta’s documentation describes sending a test_event_code with server events so they appear in Test Events, and warns to remove that code for production traffic.
For each event we confirm four things: the event arrives from both browser and server; both copies carry the same event_name and event_id; Events Manager shows them deduplicated; and parameters like value, currency and content IDs are correct. We place real test orders or leads, including one where an ad blocker is on, to confirm the server event still arrives.
After launch, we compare a week of Meta-reported conversions with your own orders or CRM leads, check event match quality per event, and look for warnings in Events Manager’s diagnostics. Only then do we suggest changing campaign optimisation, because switching optimisation events on broken data wastes spend.
How much does a Meta Conversions API setup cost, and how long does it take?
With BtechWaleTech, a Meta Conversions API setup starts at ₹40,000 and usually takes one to three weeks. A standard Shopify or WooCommerce store sits at the quicker end; a custom backend with offline and WhatsApp conversions takes longer. Multi-system event pipelines start at ₹60,000.
Quotes from others vary widely because scope varies. “CAPI setup” can mean turning on an app setting in an afternoon, or it can mean an event plan, a Pixel audit, deduplication checks, match-quality work, CRM uploads and a week of monitoring. Ask for the list of events covered and how deduplication will be verified before comparing prices.
A typical timeline: days one to three for the audit and event plan; days four to ten for implementation and staging tests; the following week for production testing, dedup verification and a comparison against your real orders. Offline or WhatsApp conversions add a few days each, depending on how quickly we get access to your CRM, billing export or WhatsApp platform.
Worked example: a hypothetical skincare brand in Bengaluru
Say a skincare brand in Bengaluru sells on a WooCommerce store, takes some orders through click-to-WhatsApp ads, and has one retail counter. Meta shows noticeably fewer purchases than the store records. This is an illustration of how we would approach it, not a real client.
The audit finds the official plugin and an old theme snippet both firing the Pixel, and no server events for orders paid through an external payment page. We remove the snippet, configure one path per event, and add server-side Purchase events from WooCommerce’s payment-complete hook, sharing the order number as event_id with the browser Pixel on the order confirmation page.
Next, the WhatsApp inbox is changed to store each chat’s ctwa_clid, and when an agent confirms an order, a Purchase business messaging event is sent. Counter sales from the billing software go to Meta daily as offline purchases, using phone numbers customers agreed to share. After a week of testing, Events Manager shows deduplicated purchases close to the store’s own count. At our starting price of ₹40,000, this scope is about a three-week project.
Meta Conversions API setup across India
We work remotely with brands and service businesses across India, so a Meta Conversions API setup for a store in Ludhiana follows the same steps as one in Mumbai. Access, testing and handover all happen online, with calls on Google Meet or Zoom.
Businesses spending on Meta ads in many cities benefit, especially D2C brands, education providers and clinics. City pages with local context: Delhi, Mumbai, Bengaluru, Ahmedabad, Kolkata, Ludhiana, Kanpur, Bhopal, Guwahati and Kozhikode.
Tracking is only one piece. Related pages: conversion tracking setup across ad platforms, email automation services for follow-up, and business process automation when the sales process behind the leads needs structure.