Conversion API Setup Guide: The Server-Side Tracking Standard for 2026

Conversion API (CAPI) is no longer optional. Browser pixel match rates have been falling for five years thanks to ITP, ETP, ad blockers, and cookie deprecation. In 2026, a pixel-only setup typically resolves only 30-50% of conversions back to a Meta user. CAPI plus deduplication routinely pushes that to 80-95%.

This guide walks through what CAPI actually is, what your setup should look like in 2026, and how to ship it without breaking what's already working.

What Is Conversion API?

CAPI is a server-to-server way of sending conversion events to Meta. Instead of relying on JavaScript firing in the user's browser, your server sends events directly to Meta's endpoint:

POST https://graph.facebook.com/v19.0/{PIXEL_ID}/events
?access_token={ACCESS_TOKEN}

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1712345678,
    "event_id": "evt_abc123",
    "action_source": "website",
    "user_data": {
      "em": ["sha256(email)"],
      "ph": ["sha256(phone)"],
      "client_ip_address": "1.2.3.4",
      "client_user_agent": "Mozilla/5.0...",
      "fbc": "fb.1.171234.AbC...",
      "fbp": "fb.1.171234.XyZ..."
    },
    "custom_data": {
      "currency": "USD",
      "value": 79.99
    }
  }]
}

The key difference: this request comes from your server, not the user's browser. Ad blockers and tracker blockers can't touch it. As long as you provide enough signals for Meta to match the event to a user, the conversion gets attributed.

Why You Need Both Pixel and CAPI

The browser pixel hasn't been replaced — it's been demoted. The recommended setup in 2026 is "redundant events": fire the same event from both the browser pixel and CAPI, with a shared event_id so Meta can deduplicate.

Why both?

• The browser pixel still resolves ~50% of conversions and provides browser-side context (cookies, IP, user agent) that improves match quality
• CAPI catches the conversions the pixel missed and adds first-party data the browser doesn't have access to
• Together they reach 80-95% match coverage; either alone leaves money on the table

Step-by-Step Rollout

Step 1: Decide where CAPI lives

Three common architectures, ordered by complexity:

1. Server-side tag manager (Google Tag Manager Server-Side, Stape): Runs your CAPI integration as a managed service. Easy to set up, less control.
2. CAPI Gateway (Meta-managed proxy): Meta-hosted infrastructure that sits in front of your site and handles event forwarding. Good middle ground.
3. Direct integration in your backend: Your application server sends events to Meta directly. Maximum control, requires engineering work.

For ecommerce on Shopify, BigCommerce, WooCommerce, etc., the platform's official Meta integration usually handles direct CAPI well — start there. For custom stacks, direct integration in your backend is typically the right call.

Step 2: Set up the access token

In Events Manager, go to your Pixel settings → Conversions API → Generate access token. Store it securely on your server. This token is the equivalent of a database password — leaks let attackers send fake conversion events.

Step 3: Send your first event

Start with a single event type, ideally Purchase, since that's where the signal-to-noise is highest. Send it from your server whenever a real purchase happens. Verify it shows up in Events Manager → Test Events within a minute.

Step 4: Add user data

This is where most setups fail. Meta's matching algorithm needs identifiers it can hash and look up against its user graph. The more you provide, the higher your event match quality (EMQ) score.

Field	Code	Match Boost
Email (hashed)	em	High
Phone (hashed)	ph	High
External ID	external_id	High (if synced)
First/last name (hashed)	fn / ln	Medium
Date of birth (hashed)	db	Medium
City / state / zip (hashed)	ct / st / zp	Medium
Click ID (fbc)	fbc	High when present
Browser ID (fbp)	fbp	Medium
IP address	client_ip_address	Low to medium
User agent	client_user_agent	Low to medium

Always SHA-256 hash PII before sending. Meta will reject unhashed values for fields that require hashing.

Step 5: Deduplicate with event_id

Generate a unique event_id for each event and send the same ID from both pixel and CAPI. Meta uses event_id + event_name as the dedup key over a 48-hour window.

// Server (CAPI) and browser (pixel) must agree on event_id
const eventId = `purchase_${orderId}_${Date.now()}`;

// Browser-side
fbq('track', 'Purchase', {
    value: 79.99, currency: 'USD'
}, { eventID: eventId });

// Server-side payload includes the same eventId
{ "event_name": "Purchase", "event_id": eventId, ... }

Without dedup, Meta will count both events and double your conversions. With dedup configured correctly, the events merge into one — and Meta picks whichever has better signal quality.

Step 6: Verify event match quality

In Events Manager, each event has an EMQ score from 0-10. You want 8+ for purchase events. Below 6 means Meta can't reliably match the event to a user, which means optimization quality drops.

Common reasons for low EMQ:

• Missing email or phone — these are the highest-value match fields
• Sending unhashed PII — Meta drops these silently
• Missing fbc/fbp — make sure your site captures them on landing and forwards them server-side
• Wrong action_source value — use "website" for web events, "app" for mobile

Step 7: Roll out to all events

Once Purchase is solid, expand to: AddToCart, InitiateCheckout, Lead, CompleteRegistration, Subscribe, and any custom events you optimize against. Each should fire from both pixel and CAPI with shared event_id and high-quality user data.

What Goes Wrong

Double-counted conversions

You ship CAPI, your reported conversion volume doubles overnight. Always a deduplication problem — pixel and CAPI are firing without a shared event_id, or the event_id format is inconsistent. Fix the dedup and the numbers normalize.

EMQ stays low

Most often this is a hashing problem. Lowercase + trim email before hashing; strip non-digits from phone; use SHA-256, not MD5. If Meta's test event tool shows the event but EMQ stays low, your hashing is wrong.

Drop in attributed conversions after rollout

Counterintuitive but common. CAPI more accurately attributes conversions, which sometimes means fewer conversions get falsely attributed to ads (reattributed to direct or organic instead). The total business hasn't changed; the picture just got more honest.

Pixel-only events hidden from Advantage+

Advantage+ Shopping favors events with strong CAPI coverage. If you've enabled Advantage+ but kept pixel-only events as your optimization target, the algorithm may be working with weaker signal than you realize. Confirm your optimization event has good CAPI coverage in Events Manager.

Beyond Web: Offline Conversions

CAPI also handles offline conversions — phone sales, in-store purchases, CRM events that happen days after the click. Sending these via CAPI lets Meta close the loop on long sales cycles and high-value, low-volume conversions.

For B2B and high-AOV ecommerce, this is often a bigger lift than fixing web tracking. A purchase that happens 14 days after a Facebook click is invisible to the pixel but trivial to send via CAPI.

The Skip-the-Plumbing Option

Setting up CAPI manually is straightforward but tedious. Ads Agents handles CAPI integration as part of standard onboarding — including dedup config, EMQ monitoring, and offline conversion uploads. The REST API exposes the same surface so it plugs into your stack without rewriting your tracking layer.

However you ship it, CAPI is the price of admission for serious Meta advertising in 2026. The advertisers without it are competing against advertisers whose algorithms have twice as much signal to work with — and that gap shows up in CPA every time.