Meta Conversions API (CAPI)

Also known as: CAPI, Conversions API, Server-side Meta tracking

What is the Meta Conversions API?

The Meta Conversions API (CAPI) is a server-to-server tracking method that sends conversion events directly from your backend to Meta. It bypasses the browser entirely. Per Meta's Conversions API documentation, CAPI is the recommended pairing for the Meta Pixel and recovers most attribution lost to iOS 14 ATT, Safari ITP, and ad blockers.

The pixel fires from JavaScript in the user's browser. CAPI fires from your server. Same event taxonomy. Different transport.

Three things make CAPI different from the pixel.

• No browser dependency. Ad blockers, ITP, and ATT do not see server-to-server traffic.
• Backend data on tap. Hashed email, phone, external_id, and order metadata that the browser never had access to.
• Survives the cookie deprecation curve. Server events do not need third-party cookies to function.

CAPI is not a replacement for the pixel. It is the second half of a required pair. For the broader category, see conversion tracking.

How CAPI works

CAPI works by your backend sending a signed HTTP POST to Meta's Graph API endpoint at graph.facebook.com/v19.0/{pixel_id}/events. Per Meta's CAPI reference, the payload carries event name, event time, event source URL, action source, user data, and custom data. Meta returns a response with the events received and any matching warnings.

The request shape.

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1714000000,
    "event_id": "order_12345",
    "event_source_url": "https://example.com/thank-you",
    "action_source": "website",
    "user_data": {
      "em": ["sha256_hashed_email"],
      "ph": ["sha256_hashed_phone"],
      "external_id": ["sha256_hashed_user_id"],
      "fbp": "fb.1.1714000000.123456",
      "fbc": "fb.1.1714000000.IwAR..."
    },
    "custom_data": {
      "currency": "USD",
      "value": 89.00
    }
  }]
}

Your server fires this request. Meta processes it. The same event the pixel fires from the browser arrives a second time, server-side, with richer user data attached.

Pixel + CAPI deduplication (event_id, fbp, fbc)

Deduplication is what keeps one purchase from counting as two. Per Meta's deduplication guide, Meta deduplicates a browser event and a server event when both share the same event_name and event_id within a 48-hour window.

The three fields that bind a pair together.

• event_id. A unique string per conversion. Use the order ID, lead ID, or a UUID generated at event time. Pass the same value to the pixel and to CAPI.
• fbp. The first-party Meta browser cookie. Captured client-side. Passed into CAPI from your server's request log or session store.
• fbc. The Meta click ID derived from the fbclid URL parameter. Captured on first visit. Persisted in your session.

A correct pair looks like this. Browser pixel fires Purchase with event_id = "order_12345". Backend fires Purchase to CAPI with the same event_id, plus the fbp and fbc it pulled from the user's session. Meta sees both. It counts one. Match Quality climbs because the server event carried a hashed email the browser never had.

Skip the event_id and Meta counts every server event as a new conversion. Reported sales double. CPA reports lie.

Setting up CAPI

Three setup paths. Pick the one that matches your stack.

Conversions API Gateway

The Conversions API Gateway is Meta's no-code option. It deploys an AWS instance that intercepts browser pixel calls and mirrors them to CAPI. Setup takes 30 to 60 minutes. AWS infrastructure costs $50 to $300 per month depending on traffic.

Use the Gateway when you have no backend access or when the team cannot ship server-side code in the next quarter.

Partner integrations

Shopify, WooCommerce, BigCommerce, HubSpot, and Segment all ship native CAPI connectors. Connect the Meta ad account, paste the access token, the integration mirrors browser events to CAPI automatically. Fastest path. Least flexible when you need custom events or non-standard parameters.

Custom server implementation

Build the integration yourself. Generate a long-lived access token in Events Manager. POST events from your backend to graph.facebook.com/v19.0/{pixel_id}/events. Match every browser event with a server twin. Hash all user data with SHA-256. Pass event_id, fbp, and fbc on every request.

Custom builds give the most control over which events fire, what data rides on them, and how external_id maps to your CRM. Plan two engineering days for a clean implementation. See server-to-server tracking for the broader pattern.

Event Match Quality (EMQ) and how to lift it

Event Match Quality is Meta's 0 to 10 score for how confidently it can match an event to a real Facebook or Instagram user. Per Meta's EMQ documentation, 7.0 is the working threshold. Below 5.0, attribution falls out of reports.

What lifts EMQ on CAPI events.

• Hash everything correctly. SHA-256, lowercase, trimmed. Email, phone, first name, last name, date of birth, city, state, country, ZIP.
• Send external_id. Your internal user ID, hashed. The single highest-impact parameter for EMQ.
• Pass fbp and fbc from the browser. Pull them from the user's session. CAPI cannot capture them on its own.
• Include client_ip_address and client_user_agent. Take them from the inbound HTTP request that triggered the conversion.
• Match casing across browser and server. [email protected] hashed and [email protected] hashed produce different hashes. Normalize before hashing.

A well-instrumented CAPI Purchase event posts EMQ between 8.0 and 9.5. A lazy one with only value and currency posts 3.0 to 5.0.

Common CAPI mistakes

Most CAPI implementations fail at the same six points.

1. No event_id deduplication. Browser and server events count as two. Reported revenue inflates. The algorithm trains on garbage.
2. Different event_id formats. Browser sends "12345". Server sends "order_12345". Strings do not match. Deduplication breaks silently.
3. Skipping fbp and fbc on the server. EMQ drops by 1 to 2 points. Match rate falls. CPA targets drift.
4. Sending unhashed PII. Plain-text emails get rejected. The event still fires, but Meta strips the user data field.
5. Missing action_source. Required field. Without it, Meta cannot route the event correctly. Common values: website, email, phone_call, chat.
6. Firing CAPI on test traffic. Test events with test_event_code go to the Test Events tab in Events Manager. Production events without that code feed real attribution.

The five-minute audit. Open Events Manager, go to the Diagnostics tab, look for warnings on your Pixel ID. Meta flags every one of these mistakes there.

Real-world example with numbers

A direct-to-consumer mattress brand spends $80,000 a month on Meta Ads. Browser pixel only. Reported ROAS averages 2.1x. Stripe revenue tells a different story.

Source	Reported Purchases	Reported Revenue	Attributed ROAS
Meta Pixel only	312	$187,000	2.34x
Stripe (truth)	498	$298,000	3.73x
Gap	186 missed	$111,000 missed	-37%

The team ships CAPI through Shopify's native integration. event_id is the Shopify order ID. fbp and fbc ride on every server event. Hashed email, phone, and external_id are added. AEM is reconfigured to put Purchase first.

Forty-five days later.

Source	Reported Purchases	Reported Revenue	Attributed ROAS	EMQ on Purchase
Pixel + CAPI	484	$290,000	3.63x	8.6
Stripe (truth)	491	$294,000	3.68x	--
Gap	7 missed	$4,000 missed	-1.4%	--

The campaigns did not change. The creative did not change. CAPI recovered 172 attributed purchases per month. The delivery algorithm now optimizes against accurate signal. Cost per acquisition on the Advantage+ Shopping campaign falls 28 percent over the next 60 days as Meta retargets the right users.

CAPI is the difference between guessing your ROAS and knowing it.

Related terms

• Meta Pixel
• Meta Pixel Events
• S2s Server To Server Tracking
• Conversion Tracking
• Ios 14 5 Att
• Purchase Event

Frequently asked questions

What is the difference between the Meta Pixel and the Conversions API?

The Meta Pixel fires from the browser using JavaScript. The Conversions API fires from your server using HTTP POST. The pixel sees browser data the server cannot. The server sees backend data the browser cannot. Run both, deduplicate by event_id, and you cover the full picture.

Do I have to use CAPI if I already have the Meta Pixel installed?

Per Meta's CAPI documentation, pairing the pixel with CAPI is the recommended setup in 2026. Browser-only attribution undercounts purchases by 20 to 40 percent on most accounts after iOS 14.5. Skipping CAPI means your delivery algorithm trains on incomplete data.

What is the Conversions API Gateway?

The Conversions API Gateway is a Meta-hosted AWS deployment that auto-mirrors browser pixel events to CAPI without code changes. It deploys in roughly 30 minutes. Setup costs sit between $50 and $300 a month in AWS fees. It is the fastest path to CAPI for accounts without a backend team.

What is a good Event Match Quality score?

Per Meta's EMQ documentation, 7.0 to 10.0 is the working range. Below 5.0, attribution drops out of reports and CPA targets drift. Sending hashed email, phone, external_id, fbp, fbc, IP, and user agent on every event is what pushes the score above 8.0.

Can the Conversions API replace the pixel completely?

Technically yes. Practically no. CAPI alone loses the fbp and fbc cookies the browser captures, which drops EMQ by 1 to 2 points. Run both. The pixel collects browser identifiers. CAPI fills in hashed user data and survives ad blockers. Together they post the highest match rate.