How Do You Know If Your Meta CAPI Is Working?

Your Meta Conversions API (CAPI) setup is working when three separate things are true: events leave your server, Meta accepts them, and Meta matches them to real people. Most verification advice checks only the first, which is why so many setups look healthy and still under-report.

The gap matters because every one of those three can fail independently, and two of them fail quietly — with a successful HTTP response and no error anywhere. This article covers how to check each layer, what Meta’s own tools do and don’t tell you, and the specific failures that look exactly like success.

What does “working” actually mean for CAPI?

It means three things, and they are not the same question:

1. Dispatch — did the event leave your server? This is the only layer you fully control. It either fired or it didn’t, and your own logs are authoritative.

2. Acceptance — did Meta take it? Meta returns an HTTP status. A 2xx means the request was well-formed enough to accept. It does not mean the event was processed, and it does not mean the payload was complete.

3. Matching — did Meta tie it to a person? An accepted event that Meta can’t resolve to a user contributes nothing to optimisation. This is measured by Event Match Quality, not by any success code.

Most “is my CAPI working” advice stops at layer one — the events are firing, so it’s working. But an integration can dispatch perfectly, get a 200 on every call, and still deliver almost no usable signal, because the payload carries an email and nothing else. All three layers have to be checked separately, because a green light on one says nothing about the next.

How do you check it in Meta’s own tools?

Meta gives you three surfaces, and they answer different questions.

Test Events is the fastest and the most under-used. In Events Manager, open your dataset, go to the Test Events tab, and copy the test event code it shows you. Attach that code to a server event as a top-level test_event_code field in the payload, then fire it. A working integration shows the event in that tab within seconds, along with the parameters it carried.

This is the single most useful check in the whole process, because it shows you the received payload — not what you think you sent. If you believe you’re sending a hashed phone number and the Test Events view shows no phone parameter, you’ve just found a bug that no status code would have revealed.

Events Manager overview shows event volume over time by source — browser, server, or both. Use it for one question only: are server events arriving at all, and at roughly the volume you expect? A flat line where you expect traffic is unambiguous. Anything subtler than that needs a different tool.

The Event Match Quality score is Meta’s rating, from 0 to 10, of how well your events match real accounts. It refreshes roughly every 48 hours over a rolling window, so it is a lagging indicator — useful for judging the health of an established setup, useless for confirming a change you made ten minutes ago.

What does Events Manager not tell you?

It doesn’t tell you what didn’t arrive.

This is the structural blind spot in platform-side verification, and it’s worth being precise about it. Events Manager is a view of events Meta received. If your server dropped an event, mis-mapped it, or never fired it, that event is simply absent — and absence looks identical to a quiet day. There’s no error, no gap marker, nothing to notice.

The only way to detect a missing event is to compare against a count Meta doesn’t have. That means reconciliation: take the number of orders in your own admin over a window, take the number of Purchase events dispatched over the same window, and compare them.

If your store admin shows 180 orders and you dispatched 174 Purchase events, six conversions went missing somewhere in your own stack — and no Meta-side dashboard would ever have told you. If the numbers match, layer one is genuinely healthy, and you can move on to asking whether the events were any good.

Run this reconciliation before you touch anything else. It’s the only check that can prove a negative.

How do you tell deduplication is actually working?

Compare your reported conversion count against your real one. If Meta reports materially more Purchases than your admin recorded, deduplication is failing and you are counting the same sale twice.

Deduplication works when the browser Pixel event and the server CAPI event carry the same event_id and the same event name. Meta then keeps the richer of the pair and discards the other. When the IDs don’t match, Meta has no way to know they’re the same conversion, so both are counted.

The specific check: fire a test purchase with both the Pixel and CAPI active, then look at the event in Test Events. A correctly deduplicated pair shows as one event with both sources attributed, not two separate entries. If you see two, your event_id values differ — usually because the browser is generating a random ID while the server uses an order ID, or because one path sends Purchase while the other sends purchase.

The failure is expensive rather than merely untidy: inflated conversion counts inflate reported ROAS, and campaigns get scaled on numbers that were never real. There’s a fuller diagnostic walkthrough in why your Meta CAPI isn’t deduplicating.

What are the failures that look like success?

Four, in rough order of how often they catch people out.

1. HTTP 200 with an unprocessed event. Meta’s response body carries an events_received count. A malformed event can return a 2xx status while that count comes back lower than what you sent. If your monitoring only checks the status code — and most monitoring does — this is invisible. Read the response body, not just the status.

2. Events arriving with almost no match data. A payload carrying only an IP address and user agent is technically a valid event. Meta accepts it, it appears in Events Manager, and it contributes close to nothing, because there’s nothing in it to match a person on. Match quality, not event count, is the measure here. The causes of a low EMQ score are almost always collection problems rather than transport problems.

3. Timestamps outside the accepted window. Meta rejects events whose event_time is more than seven days old, and clock skew on a server can push timestamps into the future, which also fails. A backfill of historical conversions frequently dies here, and the error is specific enough that it’s easy to miss in a generic error handler.

4. Consent and regional parameters missing. Without the right data-processing options, traffic from some jurisdictions is accepted and then silently discarded on Meta’s side. California traffic is the common case. Nothing in your logs will show a failure, because from your server’s point of view the send succeeded.

The pattern across all four: the thing that failed returned a success. Which is precisely why status-code monitoring alone is not verification.

How does PartialLeads show you it’s working?

By making each of the three layers directly inspectable, rather than asking you to infer health from a platform dashboard that only shows what arrived.

A 7-day health strip on the Meta CAPI page: sends over the trailing seven days, a per-day sparkline, delivery rate as a whole percent, and a failed-send count drawn from real HTTP failures. Test sends are excluded from the volume figures, so a round of testing doesn’t flatter the numbers. When no real sends exist yet, the delivery rate reads as empty rather than as a misleading zero.

A per-event activity log with the actual request and response bodies retained — the most recent 200 dispatch attempts, filterable per configuration, each carrying its event name, HTTP status code, any error, and the timestamp. Because the full request body is stored, you can open a specific event and see exactly which match parameters it carried. The access token is redacted before anything is written, so the payload is inspectable without exposing the credential. Each entry is also flagged for whether it carried a Meta click ID, which is the parameter that most affects whether the event ties back to an ad.

A per-lead dispatch indicator. On a lead’s detail view you can see whether a CAPI event was sent for that specific person and when. The leads list carries a per-platform column showing which destinations received events across the whole journey, not just the converting session.

A test send with test_event_code support, so a synthetic event can be fired from the dashboard and watched arriving in Meta’s own Test Events tab. Test sends don’t write a deduplication ledger row and don’t consume trial quota — a test isn’t a real send, and it isn’t counted as one.

Order-count and dispatch-count in the same view. The ecommerce summary shows order totals, matched and unmatched counts, and Meta fires broken out per event name — so the reconciliation described earlier can be read off one screen instead of assembled by hand from two systems.

Honest boundaries. Three things this does not do. The per-lead icon means a dispatch was attempted and not queued or skipped — it is not proof Meta accepted the event, and the activity log’s status code remains the authoritative answer for any specific lead. Failures are classified into three buckets — accepted, API error, and network error — rather than a finer-grained taxonomy. And while the raw Meta response is retained and readable per event, the events_received count inside it is not parsed into an automatic alert, so the HTTP-200-but-unprocessed case is inspectable rather than detected for you. Event timestamps are clamped to Meta’s seven-day window automatically, which prevents that particular rejection but does not resurrect the original timestamp.

What should you check, and how often?

Three checks on three different cadences.

Once, at setup: fire a test event with a test event code and confirm it appears in Test Events with the parameters you expect. Then fire a real test purchase with both Pixel and CAPI live, and confirm it appears as one deduplicated event rather than two.

Weekly: reconcile your admin order count against dispatched Purchase events for the week. This is the check that catches silent drops, and it’s the one almost nobody runs.

Monthly, or after any form change: look at Event Match Quality. It moves slowly and it responds to what your form collects far more than to how your tracking is plumbed, so it’s a review-cadence metric rather than a debugging one.

Sources

1. Meta for Developers — Conversions API documentation: https://developers.facebook.com/docs/marketing-api/conversions-api
2. Meta for Developers — Conversions API best practices: https://developers.facebook.com/docs/marketing-api/conversions-api/best-practices
3. Meta for Developers — Conversions API payload helper: https://developers.facebook.com/docs/marketing-api/conversions-api/payload-helper
4. Meta for Developers — fbp and fbc parameters: https://developers.facebook.com/documentation/ads-commerce/conversions-api/parameters/fbp-and-fbc
5. Meta Business Help — About the Conversions API: https://www.facebook.com/business/help/353532912433684