Conversions API (CAPI)

A Conversions API request is a JSON payload posted to Meta's Graph API for a pixel (in Meta's newer wording, a dataset). Every event in it has four parts.

• Event name and timeA standard event such as Lead, Schedule, CompleteRegistration or Purchase, or a custom name, with a Unix timestamp of when it actually happened. Meta accepts events up to seven days old, which is what makes CRM follow-ups possible.
• Action sourceWhere the event took place: website, app, phone_call, chat, email, physical_store, system_generated or other. A CRM stage change is system_generated; a call your team logged is phone_call.
• Customer information parametersThe matching keys: hashed email and phone, the fbc click ID and fbp browser ID, IP address, user agent, an external ID and optionally hashed name, city, postcode and country.
• Custom dataValue and currency, content IDs, lead status and anything else you want to optimise or report on. For a deal, the deal value in euros goes here.

Everything else is plumbing: the access token, the event ID for deduplication and an optional test event code that routes events to the Test Events tab in Events Manager while you check them.

The Conversions API does not replace the pixel; Meta recommends running both, which it calls a redundant setup. The pixel still does things the server cannot see, such as reading the fbp cookie and observing page views, and the API still fires when the pixel is blocked by an ad blocker, a declined banner or Safari's limits. Sent together, the two describe the same conversion from two vantage points.

• Pixel only: simple, but every event depends on the browser. Nothing arrives from a visitor with an ad blocker, and nothing can arrive weeks later from the CRM.
• Conversions API only: durable, but the server has to obtain the fbp and fbc values itself, and Meta loses the browser-side signals it uses for matching and for fraud checks.
• Both, deduplicated: the setup Meta describes as best practice. The browser sends the Lead event with an event ID; the server sends the same Lead with the same ID; Meta counts it once and keeps the richer of the two.

In practice this is what server-side tracking is for a Meta advertiser: a first-party server that receives the click, the visit and the form submit, and forwards each to Meta through the API while the pixel keeps doing its part in the browser.

If both the pixel and the server report the same form submit and Meta cannot tell they are the same, the campaign shows two leads for one person, costs per lead halve on paper and the algorithm learns from phantom conversions. Deduplication is how Meta collapses the pair.

1. Your site generates a unique event ID for the conversion, for example a UUID created when the form is submitted.
2. The pixel sends the event with that ID in its eventID field; the server sends the same event name with the same value in event_id.
3. Meta receives both. When the event name and event ID match and the two arrive within 48 hours of each other, Meta keeps the first one received and discards the duplicate.
4. Events Manager shows the outcome in the deduplication columns for each event, so you can see whether browser and server events are actually pairing up.

Two things go wrong most often. The IDs are generated separately on the client and the server and never match, so every lead is counted twice; or the same ID is reused for different people, so real leads are discarded as duplicates. A tracker that generates the ID once and hands it to both sides avoids both.

Meta never receives a plain email address from a Conversions API event. Personal identifiers are normalised (lowercased, whitespace removed, phone numbers in international format without symbols) and then hashed with SHA-256 before they leave your server. Meta hashes its own users' details the same way and compares hashes. A few technical values are sent unhashed because Meta needs them as they are.

• Email and phone (hashed)

  The strongest matches for a lead, because the person typed them into your form and used them to sign up for Meta.

• fbc and fbp (not hashed)

  fbc is built from the fbclid in the ad's landing URL; fbp is the browser ID the pixel sets. Both tie the event to a specific click and browser.

• IP and user agent (not hashed)

  Required for website events. Taken from the visitor's request, not from your server, or matching drops.

• External ID (hashed)

  Your own identifier for the person, such as the CRM contact ID. Sent from both pixel and server, it links events across the journey.

How well these parameters match is what Meta scores as Event Match Quality, a 0 to 10 rating per event in Events Manager. The parameters are the lever; the score is the readout.

A shop's conversion happens in the browser, seconds after the click. A lead generation conversion happens in stages, mostly away from the website: the form is submitted today, a sales rep marks the lead qualified on Thursday, the meeting takes place next week and the €6,000 contract is signed in three weeks. The pixel sees the first step only. The Conversions API is the channel through which the later steps reach Meta, each as its own event with the lead's hashed email, the stored click ID and the value it represents.

That is also the mechanism behind Meta's Conversion Leads optimisation for lead campaigns, which asks for CRM stage events through the API and then bids for the people who resemble your qualified leads rather than your form fillers. The Meta Conversions API guide for lead generation walks through the setup, and sending CRM data back to Meta and Google covers the same idea on both platforms.

4:35

The Conversions API is not a workaround for a broken pixel; it is the only route by which the outcomes that matter to a lead generation business, the qualified lead and the closed deal, ever reach Meta. Run it alongside the pixel, deduplicate with one event ID generated once, send the identifiers the lead gave you, and the campaign reports start to describe revenue instead of form submissions. What the pixel loses to browser restrictions is the smaller half of the story.