Skip to main content

Payload Structure

When a Face Match or ID Check session completes, Verisoul sends a POST request to your configured webhook endpoint. A webhook fires for every session outcome: pass, fail, or abandonment.

verification.face-match.completed

Fires when a Face Match session completes

verification.id-check.completed

Fires when an ID Check session completes
If your flow has a client-side dependency (the user is waiting in your UI for a pass/fail result), await the redirect. It fires the moment the session completes.Otherwise, use the webhook. It typically arrives within a few seconds of session completion, though delivery can slow during high-traffic bursts. It is the better fit for backend record-keeping and async processing.You can also use both: await the redirect for the immediate result and treat the webhook as the durable record.
Every webhook Verisoul sends uses the same signing scheme, including these. See Webhook Signature Verification to validate the x-signature header before processing a payload.

Example Success Payload: Face Match

On success, data is exactly what POST /liveness/verify-face would return for the session.

Example Success Payload: ID Check

On success, data is exactly what POST /liveness/verify-id would return for the session. It uses the same shape as Face Match plus document_signals and document_data; photo_urls nests inside document_data alongside the ID scan images.
Success payloads contain PII (name, date of birth, ID number, address for ID Check) and signed, time-limited URLs to photo/video evidence. URLs are signed at the moment the webhook is sent, so their expiration window starts when you receive them and lasts for 60 minutes. Treat the payload itself as sensitive data.

Example Error Payload


Field Reference

Top-Level Fields

data

The full verification result, identical to the verify-face or verify-id API response. For field-by-field definitions, see:

error


Error Codes

The redirect’s error_message vocabulary is broader than this list. invalid_session_id and session_id_not_found appear only in a redirect; a webhook fires only for sessions that were found and valid.

Delivery Guarantees

  • Exactly once per session. Each session fires exactly one webhook, for whichever terminal state it reaches first. This holds even if the user abandons the session or verify-face/verify-id is never called.
  • Signed. Every payload includes an x-signature header. See Webhook Signature Verification for how to verify it.
  • Retried with backoff if your endpoint returns a non-2xx response.