Update Session Data - Didit Documentation

Sometimes OCR misreads an ID, a utility bill, or a registry entry. Didit exposes three PATCH endpoints you can call to correct the extracted data without having to rerun the whole verification.

Endpoint	Use when
`PATCH /v3/session/{id}/update-data/`	Fix values extracted from an ID document on a User Verification (KYC) session
`PATCH /v3/session/{id}/update-poa-data/`	Fix values extracted from a utility bill / bank statement / lease agreement on a User Verification (KYC) session
`PATCH /v3/session/{id}/kyb/{company_uuid}/update-data/`	Fix registry-extracted fields on a Business Verification (KYB) session

All three accept your client API key or a user authorization header, and all three emit a data.updated webhook on success so your system and downstream analytics stay in sync.

Shared requirements

Authorization — client API key (standard x-api-key / Authorization bearer) or user-auth token.
Privilege —
- KYC and POA: write:sessions
- KYB company: write:businesses
Session status (KYC / POA only) — must be one of APPROVED, DECLINED, IN_REVIEW, or KYC_EXPIRED. Sessions that haven’t reached a reviewable state cannot be patched. KYB company updates have no status gate.
Feature record must exist — you can only patch KYC fields if the session captured a KYC, POA fields if it captured a POA, and KYB company fields if the session has a registry check.
Partial updates — only fields you include are changed. Omit a field to leave it as-is. Send null to clear an extra_fields key.
Webhooks — a successful update fires data.updated with session_kind: "user" or "business", and the session’s audit trail records which specific fields changed and who changed them.

Update KYC identity data

PATCH /v3/session/{sessionId}/update-data/ Patch any field extracted from the ID document. Supports graph-based multi-instance workflows via an optional node_id query parameter or body field — target a specific KYC record when a single session has multiple KYC steps.

Mutable fields

Field	Notes
`document_type`	ISO document code — `P` (passport), `ID`, `DL`, `RP`.
`document_number`	The printed document number.
`personal_number`	Personal / tax ID number when printed on the document.
`date_of_birth`	ISO 8601 date.
`date_of_issue` / `expiration_date`	ISO 8601 dates.
`issuing_state`	Issuing country, ISO 3166-1 alpha-3.
`first_name` / `last_name`	`full_name` is auto-recomputed from these two.
`gender`	`M`, `F`, or `X` when present.
`nationality`	Free text.
`marital_status`	Free text.
`place_of_birth`	Free text.
`address`	Free-text address from the document. Triggers re-geocoding.
`parsed_address`	Structured address — see the nested shape below.
`extra_fields`	Arbitrary extra fields from the ID (e.g. `blood_group`, `municipality`). Send `null` for a key to remove it.

parsed_address only accepts these nested keys: address_type, city, region, street_1, street_2, postal_code, country (ISO 3166-1 alpha-2).

Example

curl -X PATCH "https://verification.didit.me/v3/session/4c5c7f3a.../update-data/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "first_name": "John",
    "last_name": "Doe",
    "date_of_birth": "1990-01-01",
    "issuing_state": "ESP",
    "extra_fields": { "municipality": "Madrid" }
  }'

For a multi-instance graph workflow, add ?node_id=feature_ocr_2 to the URL (or pass "node_id": "feature_ocr_2" in the body) to target a specific KYC record.

Update Proof of Address (POA) data

PATCH /v3/session/{sessionId}/update-poa-data/ Patch fields extracted from a proof-of-address document. Same status gates and privilege as KYC updates. Also supports node_id for multi-instance workflows.

Mutable fields

Field	Notes
`issuing_state`	Country that issued the document, ISO 3166-1 alpha-3.
`document_type`	e.g. `utility_bill`, `bank_statement`, `lease_agreement`.
`document_language`	ISO 639-1 language of the document.
`issuer`	Utility company, bank, landlord, etc.
`issue_date`	ISO 8601 date.
`poa_address`	Address as printed on the document (free-text). Triggers re-geocoding.
`name_on_document`	Full name printed on the document.
`poa_parsed_address`	Structured address — same nested shape as KYC `parsed_address`.
`extra_fields`	Document-specific fields — bank details (`bank_account_number`, `bank_iban`, `bank_sort_code`, `bank_routing_number`, `bank_swift_bic`, `bank_branch_name`, `bank_branch_address`), `document_phone_number`, `additional_names` (list or `null`).

Example

curl -X PATCH "https://verification.didit.me/v3/session/4c5c7f3a.../update-poa-data/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "document_type": "utility_bill",
    "issuer": "Iberdrola",
    "issue_date": "2026-03-15",
    "name_on_document": "Jane Doe",
    "poa_parsed_address": {
      "street_1": "Calle Mayor 10",
      "city": "Madrid",
      "postal_code": "28013",
      "country": "ES"
    }
  }'

Update KYB company data

PATCH /v3/session/{sessionId}/kyb/{companyUuid}/update-data/ Correct registry-extracted fields on a KYB company. The endpoint edits both the canonical company columns and the raw registry_data snapshot, so the “Extracted from Registry” view in the console reflects your corrections. user_provided_data — what the end user confirmed in the hosted flow — is not modified. last_console_edit_at is stamped, and a data.updated webhook fires with trigger: "console_registry_edit".

Requirements

Privilege — write:businesses (different from the KYC / POA privilege).
The companyUuid in the URL must belong to the given sessionId, otherwise you get a 404.
No session status gate — KYB company data can be corrected at any time.

Mutable fields

Field	Notes
`company_name`	Legal name.
`registration_number`	Official registration number.
`country_code`	Country of incorporation, ISO 3166-1 alpha-3.
`incorporation_date` / `registration_date` / `dissolution_date`	ISO 8601 dates.
`tax_number`	Tax identification number.
`legal_address`	Alias for `registered_address` — lands on the canonical `registered_address` column.
`company_type`	Ltd / LLC / PLC / SA / GmbH / SL etc.
`registry_status`	`active`, `dissolved`, `struck_off`, `inactive`, etc.
`verification_status`	`verified`, `failed`, `unknown`.
`alternative_names`	Trade names, former names, DBAs.
`nature_of_business`	Short description.
`registered_capital`	Authorized / issued capital.
`website`, `email`, `phone`	Contact details.
`legal_entity_identifier`	LEI.
`location_of_registration`	City / subdivision.
`control_scheme`	Governance scheme when registry exposes it.

Any field you omit is left untouched. Any field you send is written to the canonical column (when one exists) and merged into the raw registry_data JSON. Dates are serialized as ISO 8601 strings when merged into registry_data.

Example

curl -X PATCH "https://verification.didit.me/v3/session/bs-01HJX1.../kyb/f7a9c1b2-4e6d.../update-data/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "company_name": "Acme Corporation Limited",
    "registration_number": "12345678",
    "registry_status": "active",
    "legal_address": "1 Main Street, London EC1A 1AA, United Kingdom",
    "alternative_names": "Acme Ltd, Acme Group"
  }'

Response: the full KYB company object — same shape as registry_checks[].company in the session decision.

What happens after an update

Webhook — data.updated fires on the session, with the session’s session_kind in the payload ("user" or "business"). Subscribe once at the destination level and route on session_kind.
Audit trail — the session records exactly which fields changed, the previous and new values, and (for user-auth calls) the actor email. Visible in the console’s Events tab.
Address re-geocoding — for KYC and POA updates that change address / poa_address, Didit re-runs geocoding in the background. Failures are swallowed so the update never fails because of a geocoding issue.
AML re-evaluation — KYC updates that change name / DOB / nationality can re-trigger AML screening if AML hadn’t finished on the session. Results surface on the session decision.

When not to use these endpoints

Rerunning the whole verification — if the customer has to re-take their ID photo or re-upload a document, use update-status to move the session to Resubmitted instead.
Changing profile fields on the User or Business entity — use PATCH /v3/users/{vendor_data}/ or PATCH /v3/businesses/{vendor_data}/ — those endpoints update entity-level data, not session-level data.
Updating Key People — there’s no public API to patch key-people records; that data is submitted through the hosted flow.

Errors

Status	Meaning
`401`	Missing or invalid credentials.
`403`	Caller lacks the required privilege (`write:sessions` or `write:businesses`).
`404`	Session not found, or the session doesn’t carry the feature record you’re patching (no KYC, no POA, no matching company).
`400`	Validation error — invalid country code, unknown `parsed_address` key, `extra_fields` not an object, etc.

Next steps

Retrieve session

Fetch the full decision to see the updated fields.

Update status

Approve, decline, or re-open a session after a data correction.

Webhooks

Subscribe to data.updated events.

​Shared requirements

​Update KYC identity data

​Mutable fields

​Example

​Update Proof of Address (POA) data

​Mutable fields

​Example

​Update KYB company data

​Requirements

​Mutable fields

​Example

​What happens after an update

​When not to use these endpoints

​Errors

​Next steps

Retrieve session

Update status

Webhooks

Shared requirements

Update KYC identity data

Mutable fields

Example

Update Proof of Address (POA) data

Mutable fields

Example

Update KYB company data

Requirements

Mutable fields

Example

What happens after an update

When not to use these endpoints

Errors

Next steps