For the complete documentation index, see llms.txt. This page is also available as Markdown.

Webhook

Webhook Documentation

Objective

Webhooks allow your system to receive real-time notifications as a verification operation progresses:

  • operation start,

  • evidence captures (document, selfie, NFC),

  • biometric evaluations,

  • final result.

With this, you can update business states, trigger rules, and show traceability to the end user without continuously polling.

How delivery works

  1. You configure an HTTPS reception URL in your integration.

  2. The system sends events via POST with a JSON payload.

  3. Only the events you have subscribed to in your configuration are sent.

  4. Each message includes a signature to validate authenticity.

Recommendation for your Endpoint:

  • respond quickly with 2xx when the message is accepted,

  • process asynchronously when possible,

  • handle idempotency using id of the event.

Security and authenticity

Each webhook includes:

  • header Content-Type: application/json,

  • custom security headers (if you defined them),

  • field signature within the payload.

The signature is calculated with HMAC SHA-256 over the event content and a shared integration key. You must validate this signature before considering the message trustworthy.

General webhook structure

All events follow the same base structure:

Field meanings:

  • id: unique message identifier (use to avoid duplicates).

  • type: event type (defines how to interpret data).

  • source: originating operation of the event.

  • time: UTC emission date/time.

  • data: business content of the event.

  • signature: message signature.

TypeScript Base

All events share this base envelope:

Modeling notes:

  • specversion today is always "1.0".

  • id, time and signature they do not have a closed catalog.

  • source always follows the pattern /operations/{operationId}.

  • In each event, only the values explicitly set by the current implementation are closed as an enum.

  • When an external provider or an internal stage does not define a closed catalog, the field should be left as string, Record<string, unknown> or an equivalent open structure.

Events currently available

1) Operation started

  • Type: com.idv_suite.api.workflows.operation_started.v1

  • When sent: when creating/starting an operation.

  • What it is for: open operation tracking and correlate it with your systems.

TypeScript typing:

Example:

  • Type: com.idv_suite.api.workflows.terms_consent.v1

  • When sent: when accepting or rejecting terms.

  • What it is for: legal traceability and flow continuity rules.

TypeScript typing:

Example:

3) Captured document (ID/OCR)

  • Type: com.idv_suite.api.workflows.id_captured.v1

  • When sent: when document capture and data extraction are completed.

  • What it is for: populate document data and validate consistency.

TypeScript typing:

Notes:

  • data and summary do not have a closed schema in the current implementation.

  • assets contains asset IDs associated with the event.

Example:

4) Selfie captured

  • Type: com.idv_suite.api.workflows.selfie_captured.v1

  • When sent: when face capture is completed.

  • What it is for: mark progress in the biometric stage.

TypeScript typing:

Example:

5) NFC captured

  • Type: com.idv_suite.api.workflows.nfc_captured.v1

  • When sent: when NFC reading of the document occurs.

  • What it is for: enrich and cross-check document information.

TypeScript typing:

Notes:

  • Same as in id_captured, data and summary they remain open.

Example:

6) Passive Liveness evaluated

  • Type: com.idv_suite.api.workflows.passive_liveness_evaluated.v1

  • When sent: after evaluating the passive liveness check.

  • What it is for: detect potential impersonation attempts.

TypeScript typing:

Notes:

  • diagnostic does not have a closed enum in code; the known example is "Live".

Example:

7) Injection detection

  • Type: com.idv_suite.api.workflows.injection_attack_detected.v1

  • When sent: after evaluating injection/synthetic risk.

  • What it is for: strengthen real-time anti-fraud controls.

TypeScript typing:

Example:

8) Facial Matching evaluated

  • Type: com.idv_suite.api.workflows.facial_authentication_evaluated.v1

  • When sent: when comparing the document face vs. the selfie.

  • What it is for: validate biometric correspondence.

TypeScript typing:

Notes:

  • authStatus does not have a closed enum in code. The known example is "Positive".

Example:

9) Facial enrollment

  • Type: com.idv_suite.api.workflows.facial_enrollment.v1

  • When sent: when registering a biometric identity.

  • What it is for: enable future 1:1 authentications.

TypeScript typing:

Example:

10) 1:1 facial verification

  • Type: com.idv_suite.api.workflows.facial_verification.v1

  • When sent: when validating identity against a previous enrollment.

  • What it is for: authentication or identity confirmation.

TypeScript typing:

Notes:

  • authStatus remains open; the known example is "Positive".

  • assets in this event it is emitted as string simple, not as string[].

Example:

11) Document Matching evaluated

  • Type: com.idv_suite.api.workflows.document_matching_evaluated.v1

  • When sent: when comparing two document sources within the flow.

  • What it is for: measure consistency between documents or between captures of the same holder.

TypeScript typing:

Example:

12) Operation finished

  • Type: com.idv_suite.api.workflows.operation_finished.v1

  • When sent: at operation closure (success, rejection, expiration, or error).

  • What it is for: define the final decision and close the business process.

TypeScript typing:

Example:

Last updated