How Does the Facebook Conversions API Work?

1. What is an event_id and why does it matter?

The event_id is a unique string attached to every event that the Pixel and the Conversions API both send to Meta. When Meta receives two events with the same event_id, it knows they describe the same real-world conversion, even though they arrived through different channels.

Without a shared event_id, Meta would count a single purchase as two separate purchases (one from the browser, one from the server). Your conversion numbers would inflate, your CPA would look misleadingly low, and Meta's algorithm would optimise against bad data.

Tools like PixelFlow generate the event_id once, internally, and apply it to both the Pixel and the Conversions API event for every conversion. If you set CAPI up manually, you have to handle event_id matching yourself, which is the most common source of misconfigured installs.

2. What customer data does the Conversions API send?

The Conversions API sends whatever identifiers you can pass with each event. The full list Meta supports includes hashed email, hashed phone, hashed first and last name, IP address, user agent, country, city, zip, gender, date of birth, external_id, fbp (the Facebook browser ID cookie), and fbc (the Facebook click ID).

You don't need to send all of these. The more you send, the higher your Event Match Quality score and the better Meta can match conversions to real user profiles. At minimum, you want hashed email, fbp, IP, and user agent. That alone usually pushes EMQ to 7 out of 10 or higher.

PixelFlow captures whatever data is available on the page (forms, URLs, logged-in user info) and passes it automatically. You don't need to manually pass identifiers per event.

3. Is the customer data sent to Meta secure?

Yes, as long as it's hashed before it leaves your server. The Conversions API requires that personal identifiers (email, phone, name, etc.) are SHA-256 hashed before transmission. Meta itself never sees the raw values, only the hashed versions.

Meta then hashes its own user records the same way on its side and compares hashes to find matches. If the hashes match, Meta knows the conversion belongs to a known user. If they don't, Meta has no usable information.

Tools like PixelFlow handle the hashing automatically. If you build the integration yourself, you are responsible for hashing every identifier correctly before sending it. Sending unhashed data is a common bug that breaks matching and also violates Meta's terms.

4. Does the Conversions API replace the Facebook Pixel?

No. Meta has explicitly said the Pixel and the Conversions API are complementary, not interchangeable. They are designed to run together.

The Pixel captures browser-side behaviour (page views, scroll, clicks, attribution windows). The Conversions API captures server-side conversions (purchases, refunds, subscription events) and acts as a backup for any browser event that gets blocked. Running both gives Meta the most complete picture.

The only scenario where running just the Conversions API makes sense is a pure backend product with no website at all, or visitors who block JavaScript entirely. For everything else, run both.

5. How does Meta deduplicate the events?

Through the event_id, plus a few secondary signals. When Meta receives two events with the same event_id within roughly 48 hours, it treats them as the same conversion regardless of channel.

If the event_ids don't match but the events share the same email, phone, and event_name within seconds of each other, Meta may also deduplicate based on those signals. This is the fallback mechanism. It is less reliable than event_id matching, which is why getting the event_id right is the single most important configuration step.

A misconfigured event_id is the most common cause of inflated CAPI numbers. Real-world tell: if your Meta Events Manager shows your conversions roughly doubled within a day of installing CAPI, the event_id is broken.

6. Can I see the events being sent in real time?

Yes, in two places. Meta Events Manager has a "Test Events" tab that shows every event coming in from both the Pixel and the Conversions API, including the customer data and the event_id, within seconds of it firing.

PixelFlow has its own event log in the dashboard showing every event it sent, the exact payload (in JSON), and Meta's response. So you can debug from either side.

If an event isn't showing in Events Manager but is showing in PixelFlow's log, the problem is on Meta's side (usually a Pixel ID mismatch or an expired access token). If it's not in either, the event isn't being triggered properly.

7. Do I need to do anything to keep it running once it's set up?

For a managed tool like PixelFlow, no. Once installed, the script runs continuously. Each event is captured in the browser, mirrored server-side, and sent to Meta with the correct event_id and customer data automatically.

The only ongoing maintenance is if you add new conversion events later (a new product page, a new lead funnel, a new checkout flow). At that point, you tag the new element or page in PixelFlow and the event starts flowing.

If you built CAPI yourself with GTM or the Graph API, you'll have more upkeep. Access tokens need rotation, Pixel ID changes need to propagate, and the event_id logic has to keep working across browser and server. This is one of the main reasons people move from manual CAPI setups to managed tools.

8. Could I vibe code a solution for CAPI?

Yes, technically. ChatGPT, Claude, or Cursor can generate a working Conversions API integration in an afternoon. The basic shape (hash the customer data, sign the request, POST to Meta's endpoint, log the response) is well-documented and AI tools handle the boilerplate reliably.

The problem is everything beneath the basic shape. A working CAPI implementation needs event identifiers matched correctly between the Pixel and the server, SHA-256 hashing applied to every personal identifier in the exact format Meta expects, retry logic when Meta returns a 5xx, deduplication tuned to Meta's 48-hour window, and ongoing updates whenever Meta deprecates a field or changes a payload shape.

AI tools often write code that looks correct but skips one of these in a way that's hard to spot without running events in production and watching what Meta does with them.

The deeper issue is observability. Once your vibe-coded CAPI is live, how will you know it's still working in six months?

Most homegrown installs degrade quietly. EMQ scores slip, conversions stop matching, and the only signal is your ad costs creeping up gradually. Managed tools like PixelFlow exist for the maintenance and observability piece, not just the initial install.

If you're a developer who'll watch the logs, vibe coding it is fine.

If you're a founder who needs to trust the tracking and move on, paying for a managed tool is usually cheaper than the time you'd spend debugging when something silently breaks.