Update session data

​

Shared requirements

• Authorization — client API key (standard x-api-key / Authorization bearer) or user-auth token.
• Privilege —
  • KYC and POA: write:session-status
  • 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

​

Mutable fields

​

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": "Jane",
    "last_name": "Doe",
    "date_of_birth": "1990-01-15",
    "issuing_state": "ESP",
    "extra_fields": { "municipality": "Madrid" }
  }'

​

Update Proof of Address (POA) data

​

Mutable fields

​

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

​

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

​

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"
  }'

​

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

​

Next steps