Lead Capture Recovery — Stop Silent Inquiry Loss
A production incident investigation across Vercel runtime logs, a Sanity dataset and a Next.js API route — finding that every inquiry submitted through the primary CTA was emailed to the owner but silently discarded by the CMS, while the form reported success.
The Challenge
A live lead-generation form reported success to every visitor while writing nothing to the database. The mail branch worked, so the failure was invisible: no error surfaced to the user, no alert to the owner, and the CMS inquiry collection stayed empty. The symptom had to be isolated from two healthy-looking paths — a working email send and a working Sanity dataset — before any fix could be trusted.
The Solution
Reproduced the failure through the official connector and the live runtime logs rather than by guessing from source. The investigation narrowed to a 403 from the Sanity mutation endpoint — the configured API token held read-only rights, so create was refused. A matching write was executed successfully with an OAuth session to prove the schema and project were healthy, which isolated the cause to the token and nothing else. The route was then patched so a failed persistence step can never again be reported as success, and the failure is logged with a searchable marker.
Results
Root cause isolated to read-only API credentials, not application logic or schema
Runtime log evidence captured across two production occurrences of the failure
Route patched so failed persistence can no longer masquerade as success
Dataset verified clean: 37 documents, zero orphaned test records
Duplicate Studio registrations on the default workspace identified for cleanup
This was an incident where the most dangerous property of the bug was its silence. The inquiry form on the primary call to action was returning a success response to every visitor, the owner was receiving the resulting emails, and yet the structured lead record never reached the CMS. Nothing was technically broken in a way anyone could see.
Isolating the fault. Two paths had to be separately proven healthy before suspicion could settle on the third. The email branch was read in full and confirmed to fail loudly — a missing key returns 503, a provider error returns 502 — which explained the working inbox and cleared it as a suspect. The dataset was then queried directly: 37 documents, a public read ACL, and a successful schema-valid write executed under an authenticated session. With email and CMS both proven capable, the token used by the deployed application was the only remaining variable.
The evidence that settled it. Production runtime logs recorded a 403 against the mutation endpoint with the message that the create permission was required — twice, on the inquiry route. That converts a suspicion into a fact: credentials were read-only, the write was refused, and a catch block had been absorbing the refusal and returning success regardless.
Fixing the lie, not just the symptom. The immediate operational fix is a credential with write scope. The durable engineering fix is that a failed persistence step must never again be indistinguishable from a successful one — the route now records the failure explicitly and reports it, so the next time this class of error occurs it is visible within seconds instead of discovered months later by an absent lead.