Skip to main content
Use these config fields inside each item of the features array for POST /v3/workflows/ and PATCH /v3/workflows/{settings_uuid}/.
The v3 workflow API builds a linear node-based workflow from the ordered features array. Send features in the exact execution order.

Validation rules

  • OCR defaults to all supported countries and document types when config.documents_allowed is omitted, null, or {}. If you send a custom documents_allowed object, it must contain at least one valid country and one enabled document type. Each document config can set sides to 1 for front-only capture or 2 for front-and-back capture.
  • QUESTIONNAIRE requires config.questionnaire_uuid.
  • KYB_DOCUMENTS requires config.kyb_required_document_groups.
  • FACE_MATCH must come after OCR in simple workflow requests.
  • NFC, DATABASE_VALIDATION, and person AML require OCR when they appear in the same workflow.
  • KYB sub-features such as KYB_DOCUMENTS and KYB_KEY_PEOPLE require KYB_REGISTRY earlier in the workflow.
  • A workflow is either a person (KYC) workflow or a business (KYB) workflow, never both. A workflow that uses any KYB feature (KYB_REGISTRY, KYB_DOCUMENTS, KYB_KEY_PEOPLE) may only combine it with AML, DOCUMENT_AI, QUESTIONNAIRE, PHONE_VERIFICATION, EMAIL_VERIFICATION, and IP_ANALYSIS. It cannot include person-only features such as OCR, LIVENESS, FACE_MATCH, NFC, PROOF_OF_ADDRESS, DATABASE_VALIDATION, or AGE_ESTIMATION, and a person workflow cannot include KYB features. On a business workflow DOCUMENT_AI compares any field marked is_full_name against the verified company instead of a person. To verify the people behind a company, build a separate KYC workflow and reference it from the KYB_KEY_PEOPLE node using kyb_ubo_verification_workflow, kyb_officer_verification_workflow, or kyb_shareholder_verification_workflow.
  • Action fields use DECLINE, REVIEW, or NO_ACTION unless the field below says it is restricted.
  • Score and threshold fields are numbers from 0 to 100 unless a narrower range is listed.

Common status rules

Every feature supports an optional status_rules array. Use it to override the feature status when a field condition matches.
Read the example above as: kyc.extra_fields.profession fuzzy matches Soft. Engineer with a minimum score of 80 → set the feature status to Declined. For ID Verification, target extracted extra_fields values such as kyc.extra_fields.profession, driver license class validity dates like kyc.extra_fields.dl_class_code_b_from and kyc.extra_fields.dl_class_code_b_to, or per-class restriction/information codes like kyc.extra_fields.dl_class_code_b_notes (column 12 of UK licences). These values come from the OCR result’s extra_fields object; they are not part of expected_details. For date fields, use value_type: "relative_date" with a value object shaped as { "direction": "past" | "future", "amount": number, "unit": "days" | "months" | "years" }. For example, operator: "less_than" with { "direction": "past", "amount": 3, "unit": "years" } matches dates older than three years from today.

OCR / ID Verification

Feature value: OCR. Example:

NFC / ePassport

Feature value: NFC.

Liveness

Feature value: LIVENESS.

Face Match

Feature value: FACE_MATCH.

Age Estimation

Feature value: AGE_ESTIMATION.

Phone Verification

Feature value: PHONE_VERIFICATION. Phone Verification is disabled until the organization completes its first top-up.
Phone intelligence enrichment is an optional add-on. When phone_enrichment_enabled is true, each completed phone verification is enriched with phone intelligence and billed $0.05 per request in addition to the standard phone verification cost. The score-based actions only take effect once the enrichment score is available; the trust-index, phone-type and porting actions apply as soon as enrichment runs.

Email Verification

Feature value: EMAIL_VERIFICATION.
Email intelligence enrichment is an optional add-on. When email_enrichment_enabled is true, each completed email verification is enriched with email intelligence and billed $0.05 per request in addition to the standard email verification cost. The score-based action takes effect once the enrichment score is available; the breach actions apply as soon as enrichment runs.

Database Validation

Feature value: DATABASE_VALIDATION. Example:

AML

Feature value: AML. For KYC person screening, use these fields: For KYB company screening, use these fields:

Device & IP Analysis

Feature value: IP_ANALYSIS. Example:
Use recovered_device_action separately from duplicated_device_action when you want to monitor high-confidence recovered devices before automatically declining them. This is useful during rollout because recovered-device matches are designed for fraud-ring detection but should still be calibrated against your own traffic.

Proof of Address

Feature value: PROOF_OF_ADDRESS.

Questionnaire

Feature value: QUESTIONNAIRE.

KYB Registry

Feature value: KYB_REGISTRY. kyb_registry_fields_config maps each configurable field key to {"enabled": bool, "required": bool}. enabled: false hides the field, enabled: true, required: false shows it as optional, and enabled: true, required: true makes it mandatory at submit. company_name, country_code, and region are always shown and required and cannot be configured. When the object is omitted, null, or {}, the default applies: only incorporation_date is required and every other field is optional.
Configurable field keys: registration_number, incorporation_date, legal_address, vat_number, alternative_names, tax_number, company_type, legal_entity_identifier, location_of_registration, nature_of_business, registered_capital_amount, registered_capital_currency, website, email, phone, control_scheme. See configurable registry form fields for the end-user behavior and VAT validation for how vat_number is checked against VIES.

KYB Documents

Feature value: KYB_DOCUMENTS.

KYB Key People

Feature value: KYB_KEY_PEOPLE.

Document AI

Feature value: DOCUMENT_AI. Requests one or more documents from the user and extracts the named fields you define with a vision model. Each configured field becomes a branchable value document_ai.<key>, and the step’s outcome is document_ai.status. Each entry in document_ai_documents is a document: Each entry in a document’s fields is a field: Example: