The CAPI errors that never show up anywhere
It is not the errors with messages that cost you — those get fixed. It is the six that return 200, report success and deliver the wrong thing for weeks.
Conversion integrations almost never fail loudly. They fail while reporting success — and that is what makes the problem last weeks instead of minutes.
The six below were all found in production, with a green dashboard and an empty queue.
1. Accepted is not matched
The first misunderstanding is the most basic. A 200 from the API means the event was received and is valid. It does not mean it was attributed to anyone, or that it appeared in any report.
An event without enough identity is accepted with exactly the same response as a perfect one. The difference only surfaces in match quality, days later, in aggregate.
2. The event name nobody recognises
Wrote Purchases instead of Purchase, or used a name the destination platform does not know? On most destinations that is not rejected: it becomes a custom event, with that name, in a corner of the dashboard nobody opens.
The conversion is there. It is just not the conversion the campaign optimises for.
3. The field the UI offers and the send ignores
We covered this one elsewhere, but it belongs on the list: it is common for the interface to offer an option — action source, data processing opt-out, test mode — that the sending code never reads. The choice is saved, and reaches nothing.
The check that settles it is always the same: look at the body that went out, not the screen where you configured it.
4. The filter pointing at a field that does not exist
This is the most expensive of the six. A filter comparing a field absent from the payload does not error: it evaluates false, and the integration stops delivering everything. Or, depending on how the operator was implemented, it evaluates true and delivers everything.
We measured both. In one case, a condition on a field that only exists on subscriptions dropped 100% of one-off sales — thirteen real sales in thirty-five minutes, with the dashboard showing the signal had fired and nothing being delivered.
In another, an operator the engine did not recognise fell through to the default case and returned true, so a filter meant to narrow to one specific form let every form through, with no restriction and no warning.
5. The coercion that swallows falsy values
A subtype of the previous one, subtle enough to survive many tests. A piece of code read the field and applied a default for missing values. The problem is that the default also fired for legitimate values a computer considers false: the boolean false and the number zero.
In practice: every one-off purchase, which arrives with a field marked false, was read as an empty field. The condition testing exactly that value never matched. The symptom on screen was a field showing empty while the payload, right beside it, showed the value present.
The practical lesson that stuck: a field showing empty in the audit while it exists in the payload is a sign of coercion, not of missing data.
6. The event name you configure is not the one that arrives
On checkout platforms, the name you pick when registering the webhook and the name inside the payload are frequently different. You configure purchase approved and receive a different key; you configure abandoned cart and receive a completely different shape, with no type key at all.
A filter written by reading the platform's configuration screen never matches. And since "never matches" is not an error, the integration goes quiet.
The method that finds all six
None of them shows up in an error log, because none of them is an error. All of them show up in a comparison:
- 01Count source events for the period and accepted deliveries for the same period. Divergence is the clue.
- 02Open one real delivery's payload and check it field by field against what you configured.
- 03Run the configured filter over the most recent real events and see how many would pass.
- 04Check the event name as it arrives in the payload, never as it appears in the platform's dashboard.
Those four steps take less than an hour and are worth any amount of documentation reading.
In CrazyLeads the delivered payload is stored and visible per delivery, the filter can be tested against the latest real events before publishing, and the audit shows the failing condition with the expected value and the found value, side by side.