Tracking verification progress
Every verification leaves a trail of telemetry events — the extension being installed, the consent screen being shown, notarization starting and finishing, your webhook being called. getTelemetryEvents returns that trail for one of your verifications, so you can see exactly how far a user got and where they dropped off.
Fetch the events
import { Vouch } from "@getvouch/sdk";
const vouch = new Vouch({
customerId: "1be03be8-5014-413c-835a-feddf4020da2",
apiKey: "your-api-key",
});
const { events } = await vouch.getTelemetryEvents({
requestId: "8f14e45f-ceea-4a26-9c3f-1d0f4a3f9b21",
});
for (const event of events) {
console.log(event.timestamp, event.eventType, event.origin);
}The requestId is the one returned by getDataSourceUrl or getWidgetUrl.
You can only read your own verifications
The API key you construct Vouch with scopes every call. Asking for a requestId that belongs to a different customer fails with 404 Not Found — indistinguishable from an id that was never issued, so the endpoint cannot be used to probe for other customers' verifications. There is no account-wide listing endpoint.
Response shape
getTelemetryEvents resolves to { events }, ordered oldest first:
{
"events": [
{
"eventType": "PROOF_REQUEST_CREATED",
"timestamp": "2026-07-22T09:01:12.443Z",
"origin": "Server",
"metadata": { "datasourceId": "e37a1a02-3b6e-4f38-9f6d-2b1a5c7d9e00" }
},
{
"eventType": "CONSENT_DISPLAYED",
"timestamp": "2026-07-22T09:01:31.902Z",
"origin": "Desktop",
"metadata": {
"datasourceId": "e37a1a02-3b6e-4f38-9f6d-2b1a5c7d9e00",
"geolocation": { "country": "PL", "city": "Warsaw" }
}
},
{
"eventType": "NOTARIZATION_FINISHED",
"timestamp": "2026-07-22T09:02:41.008Z",
"origin": "Desktop",
"metadata": {
"datasourceId": "e37a1a02-3b6e-4f38-9f6d-2b1a5c7d9e00"
}
}
]
}eventType
What happened. The full set is listed in Event types below, and is exported as the TelemetryEventType union so your editor will autocomplete it:
import type { TelemetryEventType } from "@getvouch/sdk";New event types are added over time. Switch on the ones you care about and ignore the rest rather than matching exhaustively, so a new event never breaks your integration.
timestamp
ISO 8601 UTC string recording when the event was captured.
origin
Which side emitted the event — "Desktop", "Android", "iOS", "Server", or "Unknown". Useful for telling a desktop-extension run apart from a mobile-app run.
metadata
Extra details attached to the event. Which keys are present depends on eventType, and every one of them is optional — a widget-created verification, for example, emits its first events before a data source has been chosen, so even datasourceId is absent there. Treat the whole object as optional and read keys defensively rather than assuming any one exists.
Only these keys are ever returned:
| Key | On which events |
|---|---|
datasourceId | Any event recorded once the data source is known |
widgetId | PROOF_REQUEST_CREATED_WITH_WIDGET, PROOF_REQUEST_DS_UPDATED |
webhookUrl | WEBHOOK_SUCCESS, WEBHOOK_FAILED |
webhookResponseError | WEBHOOK_FAILED |
geolocation | Client-emitted events, limited to country and city |
Everything else your end user's device reports — their IP address and coordinates, user agent, device model and OS, session identifiers, and the URL of the page they were on — is held back and never leaves Vouch through this API.
Event types
Not every verification produces every event — which ones you see depends on the device, the data source, and how far the user got. Events marked → status are the ones that move the verification's status.
Desktop
Emitted by the browser and the Vouch Verifier extension while the user is on desktop.
| Event | What it means |
|---|---|
DESKTOP_UNSUPPORTED_BROWSER | The user's desktop browser cannot run the extension, so the flow could not start. |
INSTALL_EXTENSION | The user was prompted to install the Vouch Verifier extension. |
EXTENSION_INSTALLED | The extension was detected as installed. |
EXTENSION_OPEN | The extension was opened and took over the flow. |
QR_CODE | The QR code was shown so the user could continue on their phone. |
SDK_STARTING | A mobile app opened the flow through an embedded Vouch SDK. |
Mobile web
Emitted by a mobile browser, before any app takes over.
| Event | What it means |
|---|---|
MOBILE_UNSUPPORTED_BROWSER | The user's mobile browser cannot run the flow. |
COPY_URL | The user copied the verification URL, usually to paste into another browser. |
Mobile app
Emitted by the Vouch Verifier mobile app.
| Event | What it means |
|---|---|
APP_OPENED | The Vouch Verifier app was opened. |
REDIRECT | The app sent the user on to the site being verified. |
USER_INSTRUCTION | An instruction was shown telling the user what to do on the target site. |
SUCCESS_MOBILE_REDIRECT | The user finished on mobile and was redirected back. |
SUCCESS_MOBILE_TO_DESKTOP | The user started on desktop, finished on mobile, and the handoff completed. |
SUCCESS_ADD_CLAIM | The resulting claim was added successfully. |
Processing
Emitted while the extension or app is on the target site, capturing the data to notarize.
| Event | What it means |
|---|---|
PROCESSING_NEW_PAGE | → status A page loaded on the target site — in practice, the user has signed in and the flow is underway. |
REQUEST_MATCHED | A network request matching the data source's rules was captured. |
PROCESSING_LOG | A diagnostic log line. Emitted repeatedly; usually noise unless you are debugging. |
PROCESSING_TIMEOUT | → status Processing ran too long and gave up. |
UPLOAD_STARTED | Upload of captured data began. |
UPLOAD_FINISHED | Upload of captured data completed. |
UPLOAD_ERROR | → status Upload failed. |
OVERLAY_SHOWN | The Vouch overlay appeared over the target site. |
OVERLAY_HIDDEN | The overlay was dismissed. |
APP_WENT_TO_BACKGROUND | The user switched away from the app mid-flow. |
APP_WENT_TO_FOREGROUND | The user came back to the app. |
USER_NAVIGATED_AWAY | The user navigated away from the page that was proving. |
PROVING_TAB_CLOSED | The tab that was proving was closed before finishing. |
Notarization
Emitted from both desktop and mobile as the proof is generated.
| Event | What it means |
|---|---|
CONSENT_DISPLAYED | The consent screen was shown to the user. |
NOTARIZATION_STARTED | → status Notarization began. |
NOTARIZATION_PENDING | A progress heartbeat while notarization runs. Repeats roughly every 5 seconds. |
NOTARIZATION_FINISHED | Notarization finished on the client. |
NOTARIZATION_ERROR | → status Notarization failed. The user can retry. |
Server
Emitted by Vouch's backend.
| Event | What it means |
|---|---|
PROOF_REQUEST_CREATED | The verification was created from a data source. |
PROOF_REQUEST_CREATED_WITH_WIDGET | The verification was created from a widget. |
PROOF_REQUEST_DS_UPDATED | A data source was selected for a widget-created verification. |
WEBPROOF_POSTED | → status The finished web proof reached Vouch. This is the event that marks a verification successful. |
WEBHOOK_SUCCESS | Your webhook accepted the delivery. |
WEBHOOK_FAILED | → status Your webhook could not be reached. The proof is fine; delivery is not. |
NOTARIZATION_MODE_OVERRIDDEN | The notarization mode was overridden for this verification. |
Video verification
Only present on video verifications.
| Event | What it means |
|---|---|
RECORDING_UPLOADED | → status The recording was uploaded and is being reviewed. |
VIDEO_VERIFICATION_APPROVED | → status The recording was accepted. |
VIDEO_VERIFICATION_REJECTED | → status The recording was rejected. |
Limits
A timeline is capped at the 1000 most recent events. Long proving sessions emit progress events continuously, so if a run exceeds the cap the oldest events are dropped and the newest — the ones that explain where it ended up — are kept.
Common uses
- Diagnosing a stuck verification — find the last event to see where the user stopped.
- Drop-off analysis — compare how many requests reach
CONSENT_DISPLAYEDversusNOTARIZATION_FINISHED. - Support — when a user reports a failure, the timeline shows whether they ever installed the extension or opened the app.
Telemetry is for observability, not for deciding whether a verification succeeded. To act on a result, use the webhook payload and verify it — telemetry events are not cryptographically signed.