Synthetic feedback-state exercise only. No real challenge, token, secret, Siteverify request or enquiry is created. This model cannot verify a person or secure an endpoint.
Keep verification and receiving states separate
For a business commissioning a protected enquiry form, a visible challenge success does not prove the server accepted the verification or that the receiving system accepted the enquiry. Agree what the visitor sees if verification expires, is reused or cannot be checked, and whether the fictional draft remains available.
An older WordPress owner discussion describes a form verification failure despite a visible success state. It is historical problem evidence, not a current diagnosis or a recommendation to disable protection. We do not adopt its plugin-change or key-rotation advice.
A filled feedback contract
Use only Demo User and chris@example.test. The verification labels below are supplied simulated outcomes, not results from Cloudflare. The draft stays in the in-memory teaching model; no browser storage or server submission is implemented.
| Simulated verification | Receiver record | Model result |
|---|---|---|
| Expired or duplicate | Not attempted | Verify again; retain draft; do not claim receipt |
| Unavailable | Not attempted | Wait with draft; no success fallback |
| Accepted | Not attempted | Receiver pending, not enquiry success |
| Accepted | Failed | This model requires fresh verification for a new submission |
| Accepted | Accepted | Demo receiver accepted; still not delivery or consultation |
| Expired | Claimed accepted | Contradictory record blocked |
Download the offline model and ten tests. Use Node 22.13 or newer and run node turnstile-retry-model.mjs. The expected test output is ten passing tests. The module exports next() for inspecting each fictional state; it is not a Turnstile implementation.
What the official documentation establishes
Cloudflare's server-side validation guidance, checked 15 October 2026, requires server verification and describes tokens as single-use with a five-minute validity. Its client error guidance discusses error callbacks and reset behaviour. A client success message alone is not server validation.
The model does not measure a token's age, generate or parse tokens, perform cryptographic verification or call Siteverify. Supplied labels are not proof. Do not put it in a production authentication or anti-spam path. The actual integration must follow current vendor guidance, validate server-side and handle the real responses; this resource grants no permission to change keys, allowed hosts or security settings.
Specify retries without weakening protection
- Agree clear expired, duplicate and temporarily unavailable messages. Never turn an unknown verification result into an accepted enquiry.
- Keep the draft available within the approved privacy design. Preserve values without logging secrets or silently storing customer details long term.
- For this teaching contract, a new submission after a receiver failure starts fresh verification. A real server may have an independently reviewed retry/idempotency design; the model does not implement one and must not be copied as a universal backend rule.
- Distinguish verification accepted, receiver accepted and actual delivery in the acceptance evidence. A provider's validation retry identifier is not by itself business-level enquiry deduplication.
Test actual integration behaviour only in an authorised environment with the proper vendor testing approach. Do not bypass a challenge, disable protection or invent a verification result to make a form pass. For a separate visible-label/error-focus check, use the bilingual form acceptance demo.
A website supplier can use this contract to discuss feedback and safe retries. It proves no spam-blocking rate, accessibility conformance, successful delivery, improved conversion or real customer enquiry.