An event row per delivery holding the source, the provider's event id, the verdict, whether the signature checked out, the raw payload as received, the normalised result, the resulting card id and any error message. A test delivery proves a mapping end to end and is recorded as a test without ever creating a card.
Also called: did the lead come through · why didn't this lead appear · form debugging · intake log
- 1Every ingestion path writes an event row regardless of outcome
- 2The raw payload is preserved so a mapping can be reconstructed after the fact
- 3The unique index on the provider event id is what makes redeliveries no-ops
- 4The event count shown in Settings is derived from these rows rather than an incrementing counter that would race concurrent webhooks
When a lead did not appear, nobody could tell whether it had been rejected, deduplicated, or never arrived at all — and the argument with the ad agency had no evidence on either side. Every delivery is now recorded with the raw payload kept: created, duplicate, merged, rejected, errored or test. A lead worth $30k to $250k deserves a black box. Test deliveries get their own verdict, so a trial submission can never create a card that a customer-facing screen might show.
- No evidence a lead ever arrived
- No safe way to test a form connection
- Silent failures in an integration nobody watches
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →