Skip to main content
Sending a requirements array on create is deprecated. Configure the checks with a verification workflow instead: run the default workflow for the country, or select one with workflowId. The requirements field is still accepted for existing integrations, but it no longer decides which checks run.

​
What it was

Before workflows, you set the checks a user had to complete by sending a requirements array when creating a verification:
The available check types are DOCUMENT_SCAN (scan an identity document) and FACE_SCAN (biometric face scan with liveness). DOCUMENT_SCAN must be paired with FACE_SCAN, so the live face can be compared against the document photo.

​
What it does now

The workflow decides which checks run. Sending requirements on create is optional and does not override that:
  • When you omit it, the checks are derived from the resolved workflow. With a workflowId, this happens once, on create. Without one, they are derived on create from the country’s default workflow, then derived again when the verification starts, from the default in force at that moment. If the default was reassigned in between, the checks follow the new default.
  • When you send it, it must be consistent with the resolved workflow. If it disagrees on whether a document is collected, creation fails with 409 and code WORKFLOW_CONFIG_INCOMPATIBLE. A sent array must also hold at least one requirement, no duplicate types, and pair DOCUMENT_SCAN with FACE_SCAN. Sending it also pins the workflow on create, so the country default is not resolved again at start.
On responses and webhooks, requirements keeps its shape and reports the checks the verification runs, so you can display them without reading the workflow’s configuration. On a verification created without workflowId or requirements, the array can still change when it starts. Read it from the STARTED webhook onward for the checks that run.