If you are running Meta ads in 2026, relying on the Meta Pixel alone is no longer enough. Browser-based tracking has been degraded by iOS privacy restrictions, ad blockers, and consent banners to the point where pixel-only setups miss over half of actual conversions. The Meta Conversions API (also called Meta CAPI) is the server-side tracking solution that closes that gap by sending conversion data directly from your server to Meta's servers, bypassing browser limitations entirely.
This guide covers everything you need to know about the Meta Conversions API: what it is, how it compares to the Meta Pixel, the three main setup methods, the critical parameters that determine your data quality, how to configure event deduplication, how to connect your CRM, and how to optimize your Event Match Quality score for maximum ad performance.
Whether you are setting up Meta CAPI for the first time or migrating from the now-discontinued Offline Conversions API, this is the only guide you need.
What Is Meta Conversions API?
The Meta Conversions API is a server-to-server tracking interface that allows you to send web events, offline events, and CRM events directly from your server to Meta's advertising platform. Unlike the Meta Pixel, which runs in the user's browser and depends on JavaScript execution, cookies, and uninterrupted page loads, the Conversions API operates independently of the browser environment.
When a user takes an action on your website, such as completing a purchase, submitting a lead form, or adding an item to their cart, the Conversions API sends that event data from your backend infrastructure to Meta. This means that even when a browser blocks the Pixel, fails to load JavaScript, or restricts cookies, Meta still receives your conversion data.
Meta designed the Conversions API as the long-term replacement for browser-dependent tracking. It now handles both online and offline conversion events through a single unified integration, which became especially important after Meta discontinued its separate Offline Conversions API in May 2025.
Meta Conversions API vs. Meta Pixel: What Is the Difference?
Understanding the difference between the Conversions API and the Meta Pixel is essential before deciding how to implement your tracking.
The Meta Pixel is a snippet of JavaScript code that loads in the user's browser. When a user visits your website or completes a conversion event, the Pixel fires and sends that data to Meta through the browser. This approach worked reliably for years, but privacy changes have steadily eroded its effectiveness. iOS 14.5's App Tracking Transparency framework, browser-based ad blockers, intelligent tracking prevention in Safari, and cookie consent banners all interfere with the Pixel's ability to fire and report accurately.
The Meta Conversions API sends the same event data, but from your server rather than the user's browser. Because server-to-server communication is not affected by ad blockers, cookie restrictions, or browser privacy features, CAPI captures conversions that the Pixel misses entirely. Stores running only pixel tracking typically see attribution accuracy drop to around 40% or lower, meaning more than half of their actual conversions go unreported.
The key differences:
Data transmission path. The Pixel sends data from the browser to Meta. The Conversions API sends data from your server to Meta.
Reliability. The Pixel depends on JavaScript execution, cookie availability, and uninterrupted page loads. CAPI depends on your server being operational, which is far more reliable and within your control.
Data richness. The Pixel can only capture what happens in the browser. CAPI can send data from any source your server has access to, including CRM records, point-of-sale systems, call tracking platforms, and offline events.
Privacy resilience. The Pixel is directly affected by iOS ATT, ad blockers, and consent frameworks. CAPI operates server-side and is not impacted by these browser-level restrictions.
Should you use both? Yes. Meta explicitly recommends running the Meta Pixel and CAPI together in what is called dual tracking. The Pixel captures browser-side signals like scroll behavior, page views, and real-time user interactions. CAPI ensures conversion events are captured reliably regardless of browser conditions. Together, they provide the most complete data picture. When you run both, you need event deduplication (covered below) to prevent double-counting.
The Three Ways to Set Up Meta Conversions API
There are three primary methods for implementing Meta CAPI, each with different levels of complexity, cost, and flexibility. The right choice depends on your technical resources, platform, and whether you advertise exclusively on Meta or across multiple platforms.
Method 1: Meta Conversions API Gateway (Simplest Setup)
The Meta Conversions API Gateway is a managed, no-code solution that Meta provides for advertisers who want server-side tracking without custom development. It works alongside your existing Meta Pixel to automatically send server-side copies of Pixel events to Meta.
How it works. The CAPI Gateway monitors your Meta Pixel events. Whenever the Gateway detects a Pixel event firing in the browser, it simultaneously sends a server-side copy of that same event to Meta. Event deduplication is handled automatically, meaning you do not need to configure event_id matching manually.
Setup time. 2 to 4 hours.
Cost. Gateway hosting services run $10 to $400+ per month depending on your event volume and hosting provider. Stape, one of the most popular Gateway hosts, offers plans starting at $10 per pixel per month.
Best for. Advertisers who need a low-maintenance, automated setup with minimal technical work. Stores on Shopify or WooCommerce that want server-side tracking without developer involvement. Meta-only advertisers who do not need to send events to Google, TikTok, or other platforms through the same infrastructure.
Limitations. The Gateway mirrors what the Pixel sees. If a user's browser blocks the Pixel from firing in the first place, the Gateway has nothing to mirror, meaning it cannot capture conversions the Pixel misses entirely. It also only works with Meta and does not serve as a centralized tracking hub for other ad platforms. Customization options are limited compared to manual implementation or server-side GTM.
Method 2: Server-Side Google Tag Manager (Best Balance of Flexibility and Control)
Server-side Google Tag Manager (sGTM) runs in a cloud environment rather than in the user's browser. It receives events from your client-side GTM container (or directly from your website) and forwards them to Meta's Conversions API endpoint, as well as to any other ad platform you use.
How it works. Your website sends events to a GA4 web tag, which forwards them to your server-side GTM container hosted in a cloud environment (typically Google Cloud Platform, AWS, or a managed provider like Stape). The server-side container then processes these events and sends them to Meta via the Conversions API, to Google via their server-side tags, and to any other platform you configure.
Setup time. 4 to 8 hours.
Cost. $10 to $50 per month for server hosting, depending on traffic volume.
Best for. Advertisers running campaigns across multiple platforms (Meta, Google, TikTok, Pinterest) who want a single centralized tracking infrastructure. Businesses that need more control over what data is sent, how it is processed, and which platforms receive it. Organizations with moderate technical resources or access to a developer or analytics specialist.
Key advantage over Gateway. sGTM is not Meta-specific. It serves as a universal server-side tracking hub, meaning you set up server-side infrastructure once and use it for every ad platform. For businesses investing in multi-platform advertising, this makes sGTM the more strategic long-term choice.
Key caveat. GA4 events often originate in the browser. If the client-side GA4 tag never fires (due to ad blockers or consent rejection), the server-side container never receives the event either. sGTM improves tracking reliability significantly but does not achieve 100% capture in all scenarios.
Method 3: Manual / Direct API Implementation (Most Customizable)
Manual implementation means your development team writes server-side code that captures conversion events and sends them directly to Meta's Conversions API endpoint via HTTP POST requests. There is no intermediary platform between your server and Meta.
How it works. Your backend application detects a conversion event (a purchase completing, a lead form submission, an appointment booking) and constructs a POST request containing the event name, event time, user data parameters, and custom data. This request is sent to the Meta Events API endpoint using your access token for authentication.
Setup time. 20 to 40 hours of developer time.
Cost. $500 to $5,000+ one-time development cost. No ongoing hosting fees beyond your existing server infrastructure.
Best for. Businesses with custom-built platforms, complex funnels, or non-standard conversion events that cannot be captured by standard Pixel events. Organizations that need to send offline events (in-store purchases, phone conversions, post-sale upsells) that never touch a website. Companies with in-house development teams that want complete control over the data pipeline.
Key advantage. Total flexibility. You control exactly what data is sent, when it is sent, and how it is structured. This is the only method that can reliably capture events that never touch a browser at all, such as CRM lifecycle changes and offline conversions.
Setup Method Comparison
Critical Meta Conversions API Parameters You Need to Know
The quality of your Conversions API implementation depends entirely on the parameters you send with each event. Sending incomplete or improperly formatted data degrades your Event Match Quality, which directly reduces how effectively Meta can optimize your campaigns.
Required Parameters
event_name. The name of the conversion event (Purchase, AddToCart, Lead, CompleteRegistration, ViewContent, InitiateCheckout, etc.). This must match Meta's standard event naming conventions.
event_time. A Unix timestamp representing when the event occurred. Send this as close to real-time as possible. Meta accepts events up to 7 days old, but delays beyond one hour reduce optimization effectiveness.
action_source. Tells Meta where the event originated. For website events, use "website." For CRM or offline events, use "system_generated" or "physical_store."
User Data Parameters
These parameters live inside the user_data object and determine how well Meta can match each event to a Facebook user profile.
em (email). Hashed with SHA256 before sending. This is the single highest-impact parameter for Event Match Quality, typically improving your score by up to 4 points.
ph (phone). Formatted in E.164 international format, then hashed with SHA256. Adds approximately 3 points to your EMQ score.
fn and ln (first name and last name). Lowercased and hashed with SHA256.
external_id. Your internal user or customer ID, hashed with SHA256. Helps Meta maintain consistent identity matching across sessions.
The fbp and fbc Parameters
These two parameters are critical for matching server events to browser sessions, and they have specific formatting requirements that many implementations get wrong.
fbp (browser ID). This value comes from the _fbp first-party cookie that the Meta Pixel sets in the user's browser. It identifies the browser session. Format: fb.1.[creation_timestamp].[random_number]. Example: fb.1.1596403881668.1116446470.
fbc (click ID). This value comes from the fbclid URL parameter that Meta appends when a user clicks your ad. Format: fb.1.[creation_timestamp].[fbclid_value]. Example: fb.1.1596403881668.AbCdEfGhIjKlMnOpQrStUvWxYz.
Critical rules for fbp and fbc. These values must NOT be hashed. Hashing them will break matching entirely. Only set fbc when a real fbclid exists in the URL. Never fabricate an fbc value, as this degrades data integrity. To send these values server-side, capture them from the browser (via hidden form fields, cookie reading on your server, or client-side JavaScript that passes them to your backend) and include them in the user_data object of your CAPI request.
Custom Data Parameters
currency. Three-letter ISO currency code (USD, EUR, GBP).
value. The monetary value of the conversion event.
content_ids. Product IDs for catalog-based events like Purchase and AddToCart.
content_type. Either "product" or "product_group" for catalog events.
How to Set Up Event Deduplication
If you are running the Meta Pixel and Conversions API together (which Meta recommends), you must configure event deduplication to prevent the same conversion from being counted twice.
How Deduplication Works
When Meta receives an event from the Pixel and a matching event from the Conversions API within a 48-hour window, it uses two fields to determine if they represent the same user action: event_name and event_id. If both fields match between the browser event and the server event, Meta recognizes them as duplicates and counts the conversion only once.
Important: Deduplication does not rely on user identifiers like email, phone, fbp, or fbc. Those parameters help with user matching (connecting the event to a Facebook profile), not event deduplication. Deduplication only checks event_name and event_id.
How to Generate and Pass event_id
The event_id must be a unique string that you generate once per user action and then pass to both the Pixel and the Conversions API.
Step 1. When a conversion event occurs, generate a unique identifier. Use a UUID v4, ULID, or any other method that produces a reliably unique string.
Step 2. Pass this identifier to the Meta Pixel as the eventID parameter in your fbq('track') call.
Step 3. Pass the same identifier to the Conversions API as the event_id parameter in your server-side POST request.
Step 4. Ensure both values are identical strings. Any mismatch, even a difference in casing or whitespace, will cause deduplication to fail and the event will be double-counted.
Event Order Matters
Meta deduplicates only when the browser event arrives first and the server event arrives second. If the server event arrives before the browser event, Meta may count both. In practice, this rarely causes issues because the Pixel fires instantaneously in the browser while server-side processing introduces a slight natural delay. However, if your server-side implementation sends events with significant latency (more than a few seconds), test your deduplication carefully.
Testing Deduplication
After implementation, verify deduplication is working by checking your Events Manager. Compare the total event count from "Browser" events and "Server" events individually against the deduplicated total. If the combined total roughly equals the individual totals (rather than doubling them), deduplication is functioning correctly. If your total event count appears doubled, review your event_id implementation. The most common failure points are mismatched strings, missing event_id on one side, or inconsistent event naming.
How to Connect Your CRM with Meta Conversions API
One of the most powerful applications of the Conversions API is sending CRM lifecycle events to Meta. This allows Meta to optimize campaigns based on what happens after the initial conversion, such as when a lead becomes a qualified opportunity, books a demo, or closes as a customer.
Without CRM integration, Meta only sees the initial form fill or signup. It has no visibility into which leads actually converted into revenue, which means it cannot distinguish between high-quality and low-quality leads when optimizing your campaigns.
Why CRM Integration Matters
When you send CRM events through CAPI, Meta can optimize for deeper funnel outcomes. Instead of optimizing for "lead" events (which may include a high percentage of unqualified submissions), you can optimize for "qualified lead," "demo booked," or even "closed-won" events. This fundamentally changes the quality of traffic Meta sends you.
HubSpot Native Integration
HubSpot offers a built-in Conversions API integration. After connecting your Facebook Ads account in HubSpot's settings, you can create conversion events that sync CRM lifecycle stage changes and form submissions directly to Meta through CAPI.
Requirements: You must have a Meta Pixel installed in your HubSpot account. Only form submissions and lifecycle stage changes that occur after creating the conversion event will be synced. Only HubSpot-created forms are supported; submissions from external forms embedded in HubSpot cannot be synced through the native integration.
Salesforce and Other CRMs
For Salesforce, Pipedrive, Zoho, and other CRMs that do not offer native Meta CAPI integrations, you have several options.
Third-party connectors. Platforms like Datahash, Stape, and LeadsBridge provide pre-built integrations that connect your CRM to Meta CAPI without custom development. Datahash supports Salesforce, HubSpot, Zoho, LeadSquared, Bitrix24, Freshsales, Microsoft Dynamics, and more.
Webhook-based setup. Most modern CRMs support webhooks in their automation tools. You can configure a webhook that fires whenever a deal changes stage or a contact reaches a specific lifecycle milestone, sending the relevant data to your Conversions API endpoint.
Server-side GTM. If you have already implemented sGTM, you can route CRM events through the same server-side container that handles your website events, keeping all your tracking infrastructure centralized.
Critical CRM Integration Detail: Preserving Click IDs
When a user clicks your Meta ad and lands on your website, the URL contains an fbclid parameter. To enable Meta to connect a CRM conversion (which may happen days or weeks later) back to the original ad click, you must capture and store the fbclid value with the contact record in your CRM at the time of initial form submission. When you later send the CRM event through CAPI, include this stored fbc value in the user_data object. Without this, Meta cannot attribute the downstream conversion to the original ad click.
What Happened to Meta's Offline Conversions API
If you previously used Meta's Offline Conversions API to track in-store purchases, phone conversions, or other offline events, you need to know that Meta permanently discontinued it in May 2025.
Version 16.0 of the Graph API was the last to support the Offline Conversions API. With Graph API v17.0 and all subsequent versions, the old system with separate Offline Datasets and manual CSV uploads is completely gone.
What this means for your setup. All offline conversion tracking now flows through the standard Conversions API. There is no longer a separate API, endpoint, or dataset type for offline events. When sending offline events through CAPI, set the action_source parameter to "physical_store" (for in-store events) or "system_generated" (for CRM or backend events) to distinguish them from website events.
Migration note. Some advertisers reported significant issues during the migration from the Offline Conversions API to CAPI, including drops of up to 70% in accepted events. If you migrated and noticed a decline in event acceptance, review your parameter formatting, ensure you are not hashing fbp and fbc values, and verify that your event_time values fall within Meta's 7-day acceptance window.
If you were using third-party tools like Zapier or Twilio Segment with the old Offline Conversions API, those integrations stopped functioning in May 2025. Both platforms now offer updated connectors for the standard Conversions API. In Zapier, make sure to select "Physical Store" as the Action Source when configuring offline conversion events.
How to Improve Your Event Match Quality Score
Event Match Quality (EMQ) is a score from 0 to 10 that Meta assigns to each of your conversion events. It measures how effectively Meta can match your server-side events to Facebook user profiles. Higher EMQ means better attribution, smarter audience optimization, and stronger campaign performance.
What EMQ Scores to Target
Purchase events: 8.8 to 9.3 is the ideal range. These events typically carry the most user data (email, phone, address) because the user has completed a transaction.
AddToCart events: Target 8.0 or above.
PageView events: 6.5 to 7.5 is normal. Users have not yet provided personal data at this stage, so matching is inherently more limited.
General benchmark: Meta's internal benchmark sits around 6 out of 10. Scores above 8 are excellent. Do not chase a perfect 10 at the expense of campaign performance. An 8.5 EMQ with strong conversion volume outperforms a 9.5 EMQ with poor campaign performance.
The Highest-Impact Improvements
Send hashed email with every event. This is the single biggest lever. Adding the em parameter typically improves EMQ by up to 4 points. Hash all email addresses with SHA256 before sending. Lowercase the email first, remove leading and trailing whitespace, then hash.
Send hashed phone number. Format in E.164 international format (example: +14155551234), then hash with SHA256. This typically adds 3 points to your EMQ score.
Include fbp and fbc. These browser and click identifiers connect server events to browser sessions. Remember: do not hash these values.
Send multiple identifiers together. Meta's matching confidence increases dramatically when you send email + phone + external_id + fbp + fbc together rather than any single identifier alone. When your events contain only one or two identifiers, Meta has limited ways to confirm user identity.
Enable Advanced Matching. Turn on Advanced Matching in your Events Manager settings. This allows the Pixel to automatically capture additional user data from form fields on your website, which supplements the data you send through CAPI.
Monitoring EMQ
Check your EMQ scores in Events Manager at least weekly. Scores update every 48 hours, but stable improvements take 1 to 2 weeks to reflect. Performance impact (lower CPA, higher ROAS) typically shows within 2 to 4 weeks as Meta's algorithm adapts to improved signal quality.
Navigate to Events Manager, select your Pixel, click on any event (like Purchase), and look for the Event Match Quality score. If any event scores below 6.0, prioritize adding the missing user data parameters outlined above.
Step-by-Step: Setting Up Meta Conversions API with Server-Side GTM
For most advertisers running multi-platform campaigns, server-side GTM offers the best balance of control, flexibility, and cost. Here is the implementation walkthrough.
Prerequisites
You need a Meta Business Manager account with admin access, a Meta Pixel already installed on your website, a Google Tag Manager account with a web container, and a server-side GTM container hosted in a cloud environment (Google Cloud Platform, AWS, or a managed provider like Stape or Taggstar).
Step 1: Generate a Meta Access Token. In Meta Events Manager, navigate to your Pixel settings. Under the Conversions API section, generate a new access token. Save this token securely. You will need it when configuring the Meta tag in your server-side GTM container.
Step 2: Configure your client-side GTM to send events to the server container. Set up GA4 event tags in your web GTM container that fire on your key conversion events (Purchase, AddToCart, Lead, etc.). Configure these tags to send data to your server-side GTM endpoint rather than (or in addition to) directly to GA4.
Step 3: Create the Meta Conversions API tag in server-side GTM. In your server-side GTM container, add the Meta Conversions API tag template. Configure it with your Pixel ID and the access token generated in Step 1. Map incoming GA4 event parameters to Meta's expected parameters (event_name, user_data fields, custom_data fields).
Step 4: Configure user data mapping. Map email, phone, first name, last name, and any other available user data parameters from your GA4 events to the corresponding Meta CAPI parameters. Ensure hashing is applied correctly (SHA256 for email, phone, name fields; no hashing for fbp and fbc).
Step 5: Set up event_id for deduplication. Generate a unique event_id on the client side (in your website JavaScript) for each conversion event. Pass this ID to both your client-side Meta Pixel fbq('track') call and to your GA4 event tag. The server-side container will forward this same event_id to Meta's CAPI, enabling deduplication.
Step 6: Test in Meta Events Manager. Go to Events Manager and open the Test Events tab. Perform conversion actions on your website and verify that events appear with both "Browser" and "Server" sources. Confirm that the deduplicated event count does not double your expected total.
Step 7: Monitor Event Match Quality. After events have been flowing for 48 hours, check your EMQ scores for each event type. If scores are below your targets, review which user data parameters are missing and add them.
Common CAPI Setup Mistakes to Avoid
Hashing fbp and fbc. These browser and click identifier parameters must be sent in plain text. Hashing them breaks Meta's ability to match server events to browser sessions.
Fabricating fbc values. Only send an fbc parameter when a real fbclid exists in the URL from an actual ad click. Sending fabricated click IDs degrades your data integrity and can harm campaign optimization.
Delayed event sending. Send events as close to real-time as possible, ideally within minutes of the conversion. Events sent hours or days later provide less optimization value to Meta's algorithm.
Mismatched event_id values. If the event_id in your Pixel call does not exactly match the event_id in your CAPI request (including casing and whitespace), deduplication fails and events are double-counted.
Forgetting to capture fbclid for CRM events. If you plan to send downstream CRM events (like "demo booked" or "closed won") through CAPI, you must capture the fbclid from the landing page URL at the time of initial conversion and store it with the contact record. Without this, Meta cannot attribute the CRM event back to the original ad click.
Using the wrong action_source. Website events should use "website." CRM events should use "system_generated." Offline or in-store events should use "physical_store." Using the wrong value can cause events to be misclassified or rejected.
Frequently Asked Questions
What is Meta CAPI?
Meta CAPI (Conversions API) is a server-to-server tracking interface that sends conversion event data directly from your server to Meta's advertising platform. It works alongside the Meta Pixel to improve tracking accuracy, bypass browser-based privacy restrictions, and provide Meta with more complete conversion data for campaign optimization. In 2026, Meta recommends every advertiser running paid campaigns implement CAPI in addition to the Pixel.
Do I still need the Meta Pixel if I have CAPI?
Yes. Meta recommends running both together. The Pixel captures real-time browser events and user behavior signals. CAPI ensures reliable conversion tracking even when browser limitations prevent the Pixel from firing. Together, they provide the most complete data. When running both, configure event deduplication using matching event_id values to prevent double-counting.
How much does Meta Conversions API cost to set up?
The cost depends on your implementation method. CAPI Gateway hosting runs $10 to $400+ per month. Server-side GTM hosting costs $10 to $50 per month. Manual/direct API implementation has no ongoing hosting cost but requires $500 to $5,000+ in developer time for the initial build. Platform-native integrations (like Shopify's built-in CAPI connector) are typically free.
What happened to Meta's Offline Conversions API?
Meta permanently discontinued the Offline Conversions API in May 2025. All offline conversion tracking (in-store purchases, phone conversions, CRM events) now flows through the standard Conversions API. When sending offline events, use the action_source parameter set to "physical_store" or "system_generated" to identify them correctly.
How do I connect my CRM to Meta Conversions API?
HubSpot offers a native CAPI integration that syncs lifecycle stage changes and form submissions directly to Meta. For Salesforce, Pipedrive, and other CRMs, use third-party connectors (Datahash, Stape, LeadsBridge) or configure webhooks that send data to your CAPI endpoint when deals change stages. The critical step is capturing and storing the fbclid click ID with each contact record so Meta can attribute downstream CRM events back to the original ad click.
What is a good Event Match Quality score?
For Purchase events, target 8.8 to 9.3. For AddToCart, target 8.0+. For PageView events, 6.5 to 7.5 is normal. Meta's internal benchmark is around 6 out of 10. The highest-impact improvement is sending hashed email addresses with every event, which can increase your EMQ score by up to 4 points.
How long does it take to see results after setting up CAPI?
Most advertisers see improved attribution data within 48 hours of implementation. Event Match Quality scores update every 48 hours. Meaningful performance improvements (lower CPA, higher ROAS) typically appear within 2 to 4 weeks as Meta's algorithm adapts to the improved signal quality. Brands report 15 to 20% campaign performance improvement on average with full CAPI implementation.
