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
You configure an HTTPS reception URL in your integration.
The system sends events via
POSTwith a JSON payload.Only the events you have subscribed to in your configuration are sent.
Each message includes a signature to validate authenticity.
Recommendation for your Endpoint:
respond quickly with
2xxwhen the message is accepted,process asynchronously when possible,
handle idempotency using
idof the event.
Security and authenticity
Each webhook includes:
header
Content-Type: application/json,custom security headers (if you defined them),
field
signaturewithin 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 interpretdata).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:
specversiontoday is always"1.0".id,timeandsignaturethey do not have a closed catalog.sourcealways 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.v1When sent: when creating/starting an operation.
What it is for: open operation tracking and correlate it with your systems.
TypeScript typing:
Example:
2) Terms consent
Type:
com.idv_suite.api.workflows.terms_consent.v1When 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.v1When sent: when document capture and data extraction are completed.
What it is for: populate document data and validate consistency.
TypeScript typing:
Notes:
dataandsummarydo not have a closed schema in the current implementation.assetscontains asset IDs associated with the event.
Example:
4) Selfie captured
Type:
com.idv_suite.api.workflows.selfie_captured.v1When 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.v1When 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,dataandsummarythey remain open.
Example:
6) Passive Liveness evaluated
Type:
com.idv_suite.api.workflows.passive_liveness_evaluated.v1When sent: after evaluating the passive liveness check.
What it is for: detect potential impersonation attempts.
TypeScript typing:
Notes:
diagnosticdoes 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.v1When 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.v1When sent: when comparing the document face vs. the selfie.
What it is for: validate biometric correspondence.
TypeScript typing:
Notes:
authStatusdoes not have a closed enum in code. The known example is"Positive".
Example:
9) Facial enrollment
Type:
com.idv_suite.api.workflows.facial_enrollment.v1When 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.v1When sent: when validating identity against a previous enrollment.
What it is for: authentication or identity confirmation.
TypeScript typing:
Notes:
authStatusremains open; the known example is"Positive".assetsin this event it is emitted asstringsimple, not asstring[].
Example:
11) Document Matching evaluated
Type:
com.idv_suite.api.workflows.document_matching_evaluated.v1When 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.v1When 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