Hosted verification statistics
Hosted verification keeps its own statistics, separate from a site key's verification statistics. The verification page answers "are real people getting through?"; this page answers a narrower question: "are my verified submissions actually reaching my destinations?" It is the only feedback you get, because submissions themselves are never stored, so this is where you notice a webhook that started failing.
Like everything in the dashboard, the numbers here are aggregate counts of delivery outcomes. They never include the contents of any submission.
Where it lives
There are two views of the same data:
| View | Scope |
|---|---|
| Per site key | Deliveries for one site key. Opened from the site key. |
| Per troop | Deliveries across every site key in the troop, for an account-wide picture. |
Pick a time range at the top: Today, Yesterday, 7 days, 28 days, or All time. Every tile and the chart follow the range you choose.
The four tiles
Four headline tiles total the range you picked:
- Webhook delivered: submissions your webhook accepted (it returned a success status).
- Webhook failed: submissions Caputchin tried but could not deliver to your webhook.
- Email delivered: submission emails the email provider accepted.
- Email failed: submission emails that could not be sent.
A tile reads zero for a destination you have not configured. If you only use a webhook, the email tiles stay at zero, and vice versa.
Delivery activity over time
The chart plots the same four outcomes across your range, so you can see when something changed rather than just that it did. Healthy hosted verification looks like the two "delivered" lines tracking your submission volume and the two "failed" lines flat near zero.
The chart collapses several underlying failure reasons into one "failed" line per destination, so the line is easy to read. Caputchin records the specific reason behind each failure for support to investigate; the categories are:
| Destination | A failure means one of |
|---|---|
| Webhook | Your endpoint returned a non-success status, it timed out, the connection itself failed, or its URL was blocked as unsafe right before delivery. |
| The email provider rejected the message, the call to it failed, or email sending is not configured on the server. |
Reading a spike
A sudden jump in either "failed" line is the signal to act, and the cause is almost always on the destination side, not Caputchin's:
- Webhook failures climbing. Your endpoint is down, slow (deliveries time out after a few seconds), returning an error status, or has moved to a URL that now looks unsafe. Check that the endpoint is up and reachable at a public
httpsURL, and send a fresh test delivery to confirm once you have fixed it. - Email failures climbing. The address is being rejected downstream, or email delivery is temporarily unavailable. Confirm the destination address and retry with a test delivery.
Because a failed delivery is not retried, a window of failures is a window of submissions that did not reach you. That is the reason to watch this page rather than assume silence means quiet.
What is not here
- No submission contents. The page counts outcomes, never payloads. If you need a record of what was submitted, store it on the receiving end of your webhook.
- No per-visitor data. Same posture as the rest of Caputchin: no IPs, no fingerprints, no identities.
See also
- Set up hosted verification: wire a destination and fire a test delivery.
- Hosted verification: the concept and the privacy posture.
- Verification statistics: the funnel for the challenge itself, separate from delivery.