Case study
A health endpoint that told the truth about the funnel
Every form rendered and every page converted, and nothing was being kept. Nobody could see that until the system reported on itself.
- capture surfaces walked end to end in a browser
- 4capture surfaces walked end to end in a browser
- endpoint that reports what is actually wired
- 1endpoint that reports what is actually wired
Figures measured 2026-10-12.
The problem
A lead funnel can be correct in code and broken in configuration. The opt-in band, three forms, and a quiz all rendered and submitted, but whether a submission was stored depended on environment settings only visible inside a hosting dashboard.
The booking button said "Book a call" while it embedded a calendar handle that returned 404.
What was built
Built a health endpoint that reports, in one JSON object, which parts of the funnel are actually connected: lead storage, email, booking, payments, analytics. It reports configuration truth, never secrets.
Changed the site so that copy follows configuration: when the calendar handle is known dead, every "book" becomes "request", because that is what the form actually does.
Drove all four capture surfaces in a real browser against a live webhook and checked the payloads field by field.
What changed
The endpoint surfaced the single most important fact about the site: submissions were logged and not stored. That turned a vague "conversion is low" into one specific setting to change.
The dead booking promise was removed from every page, and a check now fails the build if a known-dead handle starts resolving, so the exception list cannot go stale.
Inside your team
Marketing systems fail quietly between tools. A weekly dashboard is only as honest as the plumbing under it, so the first build in any new stack is the check that says what is actually connected.