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
`PATCH /v3/session/{id}/kyb/parties/{party_uuid}/`	Exempt a Key People party from verification when it can no longer complete its own check

All four accept your client API key or a user authorization header, and all four 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 and Key People party: 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.

Skip a Key People party

PATCH /v3/session/{sessionId}/kyb/parties/{partyUuid}/ Exempt a Key People party from verification - the escape hatch for a party that can never finish its own check. The usual cause is a deleted child session: once the individual KYC handed to a UBO or director is deleted, its status is frozen and it can never settle, so the KYB has nothing left that could move it out of Awaiting User. Skipping the party drops it out of the Key People aggregation, the check is recomputed on the spot, and the session can settle and be approved or declined.

Requirements

Privilege - write:businesses.
The partyUuid in the URL must belong to the given sessionId, otherwise you get a 404.
Not gated by allow_skip. That role setting limits what the applicant may skip while filling in the hosted Key People screen; this endpoint is the operator override, so it works even on roles the applicant could not have skipped.

Body

Field	Type	Notes
`is_skipped`	boolean	`true` exempts the party; `false` puts it back in scope and the check goes back to waiting on it.

requires_verification is deliberately left untouched, so an overridden party reads as requires_verification: true and is_skipped: true - the record still shows that the rules asked for a check.

Example

curl -X PATCH "https://verification.didit.me/v3/session/bs-01HJX1.../kyb/parties/0a3f1e2c-7c2f.../" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "is_skipped": true }'

Response: the updated party - the same shape as an entry of key_people_checks[].submitted.parties[] in the session decision. A data.updated webhook fires with trigger: "console_key_people_skip".

A party whose child session was deleted is flagged in the decision payload with kyc_session_deleted: true (or kyb_sub_session_deleted: true for corporate parties), and its kyc_session_url / kyb_sub_session_url is returned as null because the link no longer resolves. Deleting a child session never approves the party on its own - the Key People check drops to In Review so a human makes the call.

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.
Editing Key People details - there’s no public API to patch a party’s name, roles, or ownership; that data is submitted through the hosted flow. The one patchable field is is_skipped (see Skip a Key People party).

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 record you’re patching (no KYC, no POA, no matching company, no matching party, or a party that belongs to another session).
`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

​Skip a Key People party

​Requirements

​Body

​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

Skip a Key People party

Requirements

Body

Example

What happens after an update

When not to use these endpoints

Errors

Next steps