Meta Conversions API (CAPI): The Complete E-Commerce Guide

Your Meta Events Manager says 42 conversions yesterday. Your WooCommerce dashboard shows 67 orders. That is a 37% gap, and if you are making budget decisions based on Meta's numbers, you are flying blind.

This gap exists because the Meta Pixel runs in the browser. Ad blockers kill it. Safari's Intelligent Tracking Prevention limits it. Apple's App Tracking Transparency means only about 35% of iOS users even let it fire. And if a customer declines cookie consent in the EU, the Pixel never loads at all.

Meta's answer to this problem is the Conversions API (CAPI). It is a server-side connection that sends conversion data directly from your server to Meta, bypassing the browser entirely. This guide covers what CAPI is, how it works, how to set it up correctly, and where it still falls short.

What Is Meta Conversions API (CAPI)?

The Meta Conversions API is a server-side interface that lets you send conversion events (purchases, add-to-carts, page views) from your server directly to Meta's advertising platform. Instead of relying on JavaScript running in the customer's browser, CAPI uses a secure server-to-server connection.

Here is the difference in one sentence: the Meta Pixel asks the customer's browser to report what happened. CAPI tells Meta directly from your server.

When a customer completes a purchase on your store, here is what happens with each method:

Meta Pixel (browser-side):

1. Customer clicks "Place Order"
2. Browser executes the Meta Pixel JavaScript
3. Pixel fires a Purchase event to Meta
4. If an ad blocker is active, step 3 never happens

Conversions API (server-side):

1. Customer clicks "Place Order"
2. Your server processes the order
3. Your server sends a Purchase event directly to Meta's API
4. Ad blockers cannot interfere because the browser is not involved

Meta officially recommends running both Pixel and CAPI together, a setup they call "redundant tracking." If the Pixel fires, great. If it doesn't, CAPI has your back. And with proper deduplication, events are never counted twice.

Meta Pixel vs Conversions API: Key Differences

The numbers tell the story. With Pixel-only tracking, e-commerce stores typically lose 20-40% of conversion data. On mobile, the gap can reach 61-72%. Meta's own data shows that advertisers using both Pixel and CAPI see 13% lower cost per result and 19% more attributed purchase events compared to Pixel alone.

That is not a marginal improvement. For a store spending €10,000/month on Meta ads, 19% more attributed purchases means you can finally see which campaigns are actually driving revenue, and which ones are getting credit they don't deserve.

How Meta CAPI Works: The Technical Flow

When you implement CAPI, here is what happens behind the scenes for a typical purchase event:

1. Customer completes purchase on your store
2. Your server collects event data: order value, currency, product IDs, plus customer identifiers (hashed email, phone, FBCLID)
3. Your server sends an HTTP POST to Meta's Graph API endpoint
4. Meta receives the event, matches it to a user profile using the customer identifiers, and attributes it to the ad click
5. Meta deduplicates the event against any matching Pixel event using the event_id

Standard events for e-commerce

These are the events Meta recognizes for e-commerce optimization. Using standard event names (not custom events) is critical because Meta's algorithm optimizes specifically around these:

Key parameters you must send

Every CAPI event needs these server event parameters:

• event_name: Must match standard event names exactly (case-sensitive)
• event_time: Unix timestamp, must be within 7 days of the actual event
• event_id: Unique identifier for deduplication (more on this below)
• action_source: Set to "website" for web conversions
• user_data: Customer matching information (hashed email, phone, FBCLID, IP, user agent)

For the user_data object, Meta uses these fields to match the event to a user profile. The more you send, the higher your Event Match Quality score:

Important: Never hash fbc, fbp, client_ip_address, or client_user_agent. These must be sent in plain text. This is one of the most common CAPI implementation mistakes.

Event Deduplication: How event_id Prevents Double-Counting

If you run both Pixel and CAPI (which Meta recommends), Meta will receive two copies of every event. Without deduplication, your Events Manager will show double the actual conversions, your cost-per-purchase will look half of what it really is, and your campaign optimization will be based on inflated data.

Deduplication works through the event_id parameter. Here is the mechanism:

1. When a conversion happens, you generate a unique ID (like order_67890_purchase)
2. You send this ID with both the Pixel event and the CAPI event
3. Meta compares incoming events using the combination of event_id + event_name
4. If both match within a 48-hour window on the same Pixel ID, Meta keeps only one

Pixel-side implementation

fbq('track', 'Purchase', {
  value: 89.99,
  currency: 'EUR'
}, {eventID: 'order_67890_purchase'});

CAPI-side implementation

{
  "event_name": "Purchase",
  "event_id": "order_67890_purchase",
  "event_time": 1709913600,
  "action_source": "website",
  "user_data": { "..." : "..." },
  "custom_data": {
    "value": 89.99,
    "currency": "EUR"
  }
}

Common deduplication failures

1. Missing event_id on one side. If the Pixel fires without an event_id but CAPI sends one (or vice versa), Meta cannot match them.
2. Mismatched IDs. Even a small difference (extra space, different separator) means Meta treats them as separate events.
3. Different event names. Purchase and purchase are two different events to Meta (case-sensitive).
4. Timeout. If one event arrives more than 48 hours after the other, deduplication fails.

You can verify deduplication is working in Events Manager > Data Sources > Your Pixel > Overview. Look for the "Deduplicated" label on events. If you see raw event counts that are roughly double your actual orders, deduplication is broken.

Event Match Quality: How Meta Scores Your Data

Event Match Quality (EMQ) is Meta's 0-10 scoring system that measures how well your event data matches real Facebook and Instagram user profiles. A higher EMQ means Meta can attribute more conversions to the right ad clicks, which directly improves campaign optimization.

Target EMQ scores by event

How to improve your EMQ

1. Send multiple customer identifiers. Don't just send hashed email. Include phone, name, city, zip, and country. Each additional parameter improves matching.
2. Include fbc and fbp. These are the Facebook click ID and browser ID. They provide direct click-to-conversion matching without relying on PII hashing.
3. Hash correctly. SHA-256 only. Normalize first: lowercase emails, strip non-numeric characters from phone numbers, trim whitespace.
4. Send events in real-time. Events delayed by more than one hour lose optimization value. Meta's algorithm needs fresh data to learn.
5. Do not hash fbc, fbp, IP, or user agent. This is repeated because it's the most frequent mistake. These four parameters must be plain text.

Check your EMQ in Events Manager > Data Sources > Your Pixel > Overview tab. Click on any event to see its match quality score and specific recommendations.

Four Ways to Set Up Meta CAPI

There are four main approaches to implementing CAPI, each with different trade-offs in control, complexity, and cost:

1. Direct API (server-to-server)

You write backend code that sends events directly to Meta's Graph API. Maximum control over what data is sent, when, and how. Best for stores with custom backends or specific data transformation needs. Requires a developer who understands REST APIs and can maintain the integration.

2. Server-side Google Tag Manager (sGTM)

Deploy a server-side GTM container (typically on Google Cloud) that receives events from your website's data layer, transforms them, and forwards them to Meta. This approach handles multiple platforms simultaneously. You can send the same event to Meta, Google Ads, and TikTok from one server container. Recommended if you already use GTM and manage ads across several platforms.

3. CAPI Gateway

Meta's own managed solution. It deploys on AWS Lambda and works alongside your existing Pixel. No custom code required. The gateway intercepts Pixel events and also sends them server-side. Good for stores that want CAPI without hiring a developer. Limited customization compared to the other methods. Hosting costs scale with your event volume.

Meta has also released the Signals Gateway, which builds on CAPI Gateway by adding a first-party "Signals Pixel" hosted under your domain and a data hub that can route events to multiple platforms. Early data shows an average 23% CPA reduction on top of existing Pixel + CAPI setups.

4. Partner integrations (WooCommerce, Shopify)

Platform-specific plugins that handle CAPI automatically. Fastest setup, lowest effort, but also the least customizable. Fine for most stores, especially if your tracking needs are straightforward.

WooCommerce and Shopify: Platform-Specific Setup

WooCommerce

The official Meta for WooCommerce plugin includes built-in CAPI support:

1. Install and activate "Facebook for WooCommerce" (now "Meta for WooCommerce")
2. Navigate to Marketing > Facebook and click Get Started
3. Connect your Facebook Business Manager and select your Pixel
4. In Events Manager > Data Sources > Settings, go to the Conversions API section
5. Generate an access token and paste it into the plugin settings
6. The plugin will automatically send Purchase, AddToCart, InitiateCheckout, ViewContent, and PageView events via CAPI

Known limitations:

• Some WooCommerce caching plugins with JavaScript optimization/grouping settings interfere with Pixel tracking code. If your Pixel events stop firing, disable JS grouping in your caching plugin.
• The plugin's simplified CAPI implementation may still produce lower EMQ scores compared to a custom setup. The plugin sends fewer customer parameters than what's possible via direct API.
• Not compatible with "Checkout on Facebook and Instagram."

For stores that need more control, capturing FBCLID directly in WooCommerce order metadata gives you the raw click ID for custom attribution logic. This works alongside the plugin's CAPI integration.

Shopify

Shopify's native Facebook & Instagram app handles CAPI:

1. Install "Facebook & Instagram by Meta" from the Shopify App Store
2. Connect your Facebook Business Manager
3. In data-sharing settings, select Maximum (this enables CAPI)
4. Deduplication is handled automatically with matching event IDs

Data sharing levels in Shopify:

Meta reports that Shopify stores using CAPI at the Maximum setting see up to 70% improvement in Event Match Rate.

Privacy and Compliance: CAPI in a Post-ATT World

CAPI is not a magic bullet for privacy restrictions. It is a more resilient data pipeline, but it still operates within the same legal framework. Here is where CAPI helps, and where it doesn't.

Where CAPI helps

Ad blockers. Over 912 million people worldwide use ad blockers, a number expected to surpass 1 billion by 2026. Ad blockers work by intercepting browser requests to known tracking domains. Since CAPI sends data from your server (not the browser), ad blockers cannot detect or block it.

iOS App Tracking Transparency (ATT). Since iOS 14.5, Apple requires apps to ask for tracking permission. Only about 35% of users opt in globally as of 2025. ATT limits the Meta Pixel's ability to fire within apps and in-app browsers. CAPI bypasses this because the server-to-server connection is independent of the device's tracking settings. Meta estimated that iOS 14.5 ATT cost them $10 billion in revenue in 2022 alone.

Safari ITP and Firefox ETP. Safari has blocked third-party cookies since 2020 and limits first-party cookies set by JavaScript to 7 days. Firefox blocks known trackers by default. Together, these browsers represent roughly 30% of web traffic. CAPI is not dependent on browser cookies for data transmission.

Where CAPI does not help

GDPR consent. If your customer is in the EU and has not consented to marketing data processing, you should not send their personal data to Meta via CAPI either. Server-side does not mean consent-free. You still need a Consent Management Platform (CMP) and must respect the user's choice. For a detailed breakdown of consent requirements by country, see our guide on what you can and can't track by region.

Meta's data_processing_options parameter. CAPI supports privacy compliance flags for GDPR and CCPA. You can signal to Meta that a user has not consented, and Meta will limit how that data is used. But you must implement this logic yourself.

Data you can still send without consent. Aggregated, non-personal event data (like "a purchase of €89 happened") without any user identifiers is generally permissible. However, this drastically reduces EMQ since Meta cannot match the event to a user profile.

Common CAPI Mistakes That Kill Ad Performance

1. Not implementing deduplication at all. If you run both Pixel and CAPI without matching event_id values, every conversion is counted twice. Your cost-per-purchase looks half of reality, and Meta's algorithm optimizes toward the wrong targets.

2. Hashing fbc and fbp parameters. These are the Facebook click ID and browser ID. They must be sent in plain text. If you hash them, Meta cannot match conversions to ad clicks, and your EMQ drops significantly.

3. Sending events hours or days late. Meta accepts events up to 7 days old, but events delayed beyond one hour contribute almost nothing to campaign optimization. The algorithm needs real-time signals to learn what's working.

4. Missing customer data parameters. Sending only hashed email gives Meta one matching signal. Adding phone, name, city, and zip can increase match accuracy by 20-40%. More parameters means higher EMQ, which means better attribution.

5. Wrong hashing implementation. The most common errors: not lowering case before hashing email, not stripping non-numeric characters from phone numbers, double-hashing (hashing already hashed data), or using MD5 instead of SHA-256.

6. Using an expiring access token. If you generate a user access token instead of a system user token, it will expire and silently stop sending events. Use a system user token created in Business Settings so it persists regardless of team member changes.

7. Ignoring Events Manager warnings. Meta's Events Manager shows deduplication status, EMQ scores, and error rates. If you don't check it at least weekly, you won't catch problems until your ROAS craters.

Why CAPI Alone Is Still Not Enough

CAPI solves a real problem. But it has fundamental limitations that no configuration tweak can fix.

Meta only sees Meta. CAPI tells Meta about conversions driven by Meta ads. It cannot tell you how Meta's contribution compares to Google Ads, organic search, email campaigns, or direct traffic. You get Meta's version of the truth, from inside Meta's walled garden.

Self-attribution bias. Meta's algorithm is incentivized to attribute conversions to Meta ads. If a customer clicks a Meta ad on Monday, then clicks a Google ad on Wednesday, then purchases on Thursday, Meta will still claim that conversion through its 7-day click attribution window. Google will also claim it. Both platforms report the same sale, and your total "attributed revenue" exceeds your actual revenue.

EU consent still limits data flow. CAPI sends data server-side, but privacy laws in most of Europe require consent before processing personal data for advertising purposes. If 50% of your EU customers decline consent, CAPI cannot send their purchase data with user identifiers. Your attribution gap narrows but doesn't close.

No cross-platform deduplication. CAPI deduplicates between Pixel and CAPI for the same event. It does not deduplicate between Meta and Google. If a customer interacts with ads on both platforms, both will claim the conversion. You need an independent system to reconcile this.

This is where the real question becomes: who do you trust to tell you which ad actually drove the sale? The ad platform that sold you the ad, or a system that starts from the actual order?

How Order-Based Attribution Goes Beyond CAPI

At Enalitica, we took a different approach. Instead of starting from the ad platform and trying to match events to orders, we start from the order and trace it back to the ad click.

Here is how it works: when a customer arrives at your WooCommerce or Shopify store from a Meta ad, the URL contains an fbclid parameter. Enalitica captures this click ID at the server level when the order is created, not through browser JavaScript. This means the FBCLID is stored in your order database regardless of ad blockers, cookie consent, or Safari ITP.

This is fundamentally different from CAPI in one key way: CAPI sends your data to Meta. Enalitica starts from your orders and uses click IDs to determine which platform actually drove each sale.

What this looks like in practice

Consider a customer who clicks a Meta ad, browses your store, then returns via a Google ad two days later and purchases:

Enalitica captures both the FBCLID and the GCLID. The most recent valid click ID determines primary attribution (Google in this case), while Meta gets credited as an assist (influenced revenue). One order, one source of truth, no inflated numbers.

Privacy resilience comparison

Enalitica also sends conversion events back to Meta and Google via their respective Conversions APIs, closing the loop for ad optimization. So you get the best of both worlds: accurate, independent attribution from your orders, plus the campaign optimization signals that Meta and Google need.

The FBCLID attribution window in Enalitica follows Meta's standard 28-day window. For GCLID, it's 90 days. Both are validated with timestamps so expired click IDs don't produce false attribution. For more on how click ID capture works at the order level, see our guide on capturing GCLID and FBCLID in WooCommerce.

Want to see how your Meta and Google attribution actually compares when measured from real orders? Book a demo and we'll show you the gaps in your current setup.

Implementation Checklist

Whether you use CAPI alone or pair it with order-based attribution, here are the steps to get your Meta tracking right:

1. Audit your current setup. Open Events Manager, check which events are firing, look at the source column (Browser, Server, or both). If everything says "Browser," you have Pixel only and no CAPI.

2. Choose your implementation method. For most WooCommerce and Shopify stores, the native plugin is the fastest path. For stores managing ads across multiple platforms, server-side GTM gives more flexibility.

3. Implement deduplication from day one. Generate a unique event_id for each conversion and send it through both Pixel and CAPI. Do not defer this. Launching CAPI without deduplication is worse than not having CAPI because it doubles your conversion count.

4. Maximize your customer data parameters. Send hashed email, phone, name, city, state, zip, and country with every Purchase event. Include fbc and fbp in plain text. Check your EMQ score and aim for 8.0+ on Purchase events.

5. Monitor weekly. Check Events Manager every week for deduplication status, EMQ trends, and error rates. Set up email alerts for drops in event volume.

6. Consider independent attribution. If you advertise on both Meta and Google (most e-commerce stores do), CAPI alone gives you Meta's self-reported numbers. To understand actual cross-platform performance, you need a system that attributes orders independently of the ad platforms, like multi-touch attribution based on real order data.

FAQ

Does the Meta Pixel Helper browser extension detect CAPI events?

No. The Pixel Helper only shows events fired by the Meta Pixel (client-side JavaScript). CAPI events are sent server-to-server and are invisible to the browser extension. To verify CAPI events, use Events Manager > Test Events or check the event source column in your Data Sources overview. Events from CAPI show "Server" as the source.

What is the Meta CAPI access token and how do I get one?

The access token authenticates your server's API calls to Meta. Generate one in Events Manager > Data Sources > Settings > Conversions API section. For production use, create a System User in Business Settings and generate a token through that. System User tokens don't expire when team members leave, unlike personal user tokens.

Can I use Meta CAPI for offline conversions (CRM, in-store)?

Yes. As of Graph API v17.0, the old Offline Conversions API has been deprecated and merged into CAPI. You can now send offline events (in-store purchases, call center conversions, CRM events) through the same CAPI endpoint. Set action_source to "physical_store" or "system_generated" instead of "website".

How is CAPI different from the old Offline Conversions API?

They have merged. Meta deprecated the standalone Offline Conversions API starting with Graph API v17.0 (May 2025). All offline conversion tracking now flows through the standard Conversions API. If you were using the old API, you need to migrate to CAPI endpoints.

What happens if I implement CAPI without deduplication?

Every conversion that fires on both Pixel and CAPI will be counted twice. Your reported cost-per-purchase will be halved (looks great, isn't real), and Meta's optimization algorithm will train on inflated data. This can actually worsen campaign performance because the algorithm thinks it's finding more conversions than actually exist.

Can CAPI track across multiple domains?

Yes, as long as all domains share the same Pixel ID and send events to the same dataset. CAPI sends the event_source_url parameter, which tells Meta which domain the event came from. For accurate cross-domain tracking, ensure the fbc parameter is consistent. If a customer moves between domains and loses the fbc cookie, use external_id (your customer ID) as a fallback identifier.

What is the minimum Graph API version for CAPI in 2026?

As of September 2025, Meta requires Graph API v22.0 or later for all API calls. By February 2026, you'll need v23.0 or v24.0. If your integration uses an older version, it will silently fail. Check your implementation's API version and update proactively.

How do GCLID and FBCLID differ for attribution purposes?

GCLID is Google's click identifier with a 90-day attribution window. FBCLID is Meta's with a 28-day window. Both serve the same purpose (linking an ad click to a conversion) but for different platforms. For a detailed comparison of Google's click identifiers, see our guide on GCLID vs GBRAID vs WBRAID.

Is CAPI GDPR-compliant?

CAPI itself is a data pipeline, not a consent mechanism. Whether your CAPI implementation is GDPR-compliant depends entirely on how you handle consent. If you only send data for users who have consented to marketing tracking, and you use Meta's data_processing_options parameter to flag non-consented events, your implementation can be compliant. Using a Consent Management Platform (CMP) and honoring user preferences is required regardless of whether you use Pixel, CAPI, or both.

Why did Meta build CAPI? What problem does it solve?

Apple's iOS 14.5 ATT framework cost Meta an estimated $10 billion in revenue in 2022 alone. Browser-based tracking was becoming unreliable due to ad blockers, ITP, and consent requirements. CAPI was Meta's strategic response: move the data pipeline from the browser (which Apple, ad blockers, and privacy laws can restrict) to the server (which the advertiser controls).