> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Sitzungsdaten-API: KYC- & KYB-Felder aktualisieren

> Mit Didit OCR-Daten bestehender Sitzungen korrigieren: KYC-, POA- und KYB-Felder. Drei PATCH-Endpoints, Teilupdates, Webhooks, pro Aufruf.



Prompt zum Aktualisieren der Sitzungsdaten
        Prompt in die Zwischenablage kopieren



      
      

\<pre>

\`Correct OCR-extracted fields on a finished Didit verification session — KYC identity, Proof of Address, or KYB company data.

There are THREE separate PATCH endpoints. Pick the one that matches the feature record you need to fix.

1\) Update KYC identity data
PATCH https://verification.didit.me/v3/session/{session_id}/update-data/
\- Auth: x-api-key (client) or user-auth token. Privilege: write:sessions.
\- Session status must be one of Approved, Declined, In Review, Kyc Expired.
\- Session must have a captured KYC feature record.
\- Optional query / body param node_id targets a specific KYC instance in multi-step workflows (e.g. node_id=feature_ocr_2).
\- Mutable fields: document_type ("P", "ID", "DL", "RP"), document_number, personal_number, date_of_birth (ISO date), date_of_issue, expiration_date, issuing_state (ISO 3166-1 alpha-3), first_name, last_name (full_name is auto-recomputed), gender ("M"|"F"|"X"), nationality, marital_status, place_of_birth, address (free-text — triggers re-geocoding), parsed_address (nested: address_type, city, region, street_1, street_2, postal_code, country [ISO 3166-1 alpha-2]), extra_fields (object — send null on a key to remove it).

2\) Update Proof of Address (POA) data
PATCH https://verification.didit.me/v3/session/{session_id}/update-poa-data/
\- Same auth + privilege + status gate as KYC.
\- Session must have a captured POA record. node_id supported.
\- Mutable fields: issuing_state (ISO-3), document_type ("utility_bill" | "bank_statement" | "lease_agreement"), document_language (ISO 639-1), issuer, issue_date (ISO date), poa_address (free-text — triggers re-geocoding), name_on_document, poa_parsed_address (same nested shape as KYC parsed_address), extra_fields (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).

3\) Update KYB company data
PATCH https://verification.didit.me/v3/session/{session_id}/kyb/{company_uuid}/update-data/
\- Privilege: write:businesses (NOT write:sessions).
\- No status gate — KYB company data can be corrected at any time.
\- company_uuid must belong to that session_id (else 404).
\- Mutable fields: company_name, registration_number, country_code (ISO-3), incorporation_date / registration_date / dissolution_date, tax_number, legal_address (lands on registered_address), company_type, registry_status ("active" | "dissolved" | "struck_off" | "inactive" | ...), verification_status ("verified" | "failed" | "unknown"), alternative_names, nature_of_business, registered_capital, website, email, phone, legal_entity_identifier, location_of_registration, control_scheme.
\- Edits BOTH the canonical column and registry_data. user_provided_data is never touched.

4\) Skip (or re-require) a Key People party
PATCH https://verification.didit.me/v3/session/{session_id}/kyb/parties/{party_uuid}/
\- Privilege: write:businesses.
\- Body: { "is_skipped": true } to exempt the party, { "is_skipped": false } to put it back in scope.
\- party_uuid must belong to that session_id (else 404).
\- Use it when a party can no longer finish its own check - most often because the linked individual KYC session was deleted - and the KYB is stuck in Awaiting User with nothing left that can move it.
\- Independent of the role's allow_skip setting: that flag limits what the applicant may skip in the hosted flow, not what you may override.
\- requires_verification is left untouched, so the override stays visible as requires_verification: true + is_skipped: true.
\- Recomputes the Key People check and the parent session status immediately, and fires data.updated with trigger: "console_key_people_skip".

Common contract for all four:
\- PATCH semantics — only fields you send are updated. Omit a field to leave it as-is. Send null on an extra_fields key to remove it.
\- A successful update fires a data.updated webhook (with session_kind: "user" or "business"). KYB company updates carry trigger: "console_registry_edit".
\- The audit trail records changed fields, previous + new values, and (for user-auth) the actor email.

KYC curl example:
curl -X PATCH "https://verification.didit.me/v3/session/<SESSION_ID>/update-data/" \
-H "x-api-key: <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" }
}'

Response: the updated record (KYC / POA / KYB company shape — same fields as in the session decision).

Failure modes:
\- 401 — missing or invalid credentials.
\- 403 — { "detail": "You do not have permission to perform this action." } — caller lacks write:sessions (KYC/POA) or write:businesses (KYB company).
\- 404 — { "detail": "Not found." } — session, node_id, or company_uuid not found; OR the session does not carry the feature record you are patching (no KYC / no POA / no matching company).
\- 400 — validation error: invalid country code, unknown parsed_address key, extra_fields not an object, etc. Returned as { "<field>": ["..."] }.

When NOT to use these endpoints:
\- To ask the user to retake the document → use PATCH /v3/session/{id}/update-status/ with new_status: "Resubmitted" (see /sessions-api/update-status).
\- To change entity-level data → use /v3/users/{vendor_data}/ or /v3/businesses/{vendor_data}/.
\- To edit Key People names / roles / ownership - no public API; that data is submitted through the hosted flow. Only the is_skipped flag is patchable (endpoint 4).

Side effects:
\- Changes to KYC name / DOB / nationality can re-trigger AML if AML was still running.
\- Changes to address / poa_address re-run geocoding asynchronously (failures swallowed — they never fail the update).

For end-to-end Didit integration, paste in the full prompt at /integration/integration-prompt.`

\</pre>



      
      

Einfügen in

Manchmal liest OCR einen Ausweis, eine Versorgungsrechnung oder einen Eintrag im Unternehmensregister falsch aus. Didit stellt drei PATCH-Endpoints bereit, mit denen Sie die extrahierten Daten korrigieren können, ohne die gesamte Verifizierung erneut durchlaufen zu lassen.| Endpoint | Verwenden, wenn |
| - | - |
| [`PATCH /v3/session/{id}/update-data/`](#kyc-identitätsdaten-aktualisieren) | Aus einem Ausweisdokument extrahierte Werte in einer **Benutzerverifizierung (KYC)**-Sitzung korrigiert werden sollen |
| [`PATCH /v3/session/{id}/update-poa-data/`](#adressnachweis-daten-poa-aktualisieren) | Aus einer Versorgungsrechnung, einem Kontoauszug oder einem Mietvertrag extrahierte Werte in einer **Benutzerverifizierung (KYC)**-Sitzung korrigiert werden sollen |
| [`PATCH /v3/session/{id}/kyb/{company_uuid}/update-data/`](#kyb-unternehmensdaten-aktualisieren) | Aus dem Unternehmensregister extrahierte Felder in einer **Unternehmensverifizierung (KYB)**-Sitzung korrigiert werden sollen |
| [`PATCH /v3/session/{id}/kyb/parties/{party_uuid}/`](#eine-partei-der-schlüsselpersonen-überspringen) | Eine Schlüsselpersonen-Partei von der Verifizierung ausnehmen, wenn sie ihre eigene Prüfung nicht mehr abschließen kann |Alle vier Endpoints akzeptieren Ihren **API-Schlüssel** oder einen **Benutzer-Autorisierungs-Header**, und alle vier senden bei Erfolg ein `data.updated`-Webhook, damit Ihr System und Ihre nachgelagerten Analysen synchron bleiben.## Gemeinsame Anforderungen- **Autorisierung**: API-Schlüssel (standardmäßiger `x-api-key`- bzw. `Authorization`-Bearer) oder Benutzer-Autorisierungstoken.
- **Berechtigung**:
  * KYC und POA: `write:sessions`
  * KYB-Unternehmensdaten und Schlüsselpersonen-Partei: `write:businesses`
- **Sitzungsstatus** (nur KYC / POA): muss einer der folgenden Werte sein: `APPROVED`, `DECLINED`, `IN_REVIEW` oder `KYC_EXPIRED`. Sitzungen, die noch keinen prüfbaren Zustand erreicht haben, können nicht geändert werden. Für KYB-Unternehmensaktualisierungen gibt es keine Statusbeschränkung.
- **Datensatz der Funktion muss vorhanden sein**: KYC-Felder können nur geändert werden, wenn die Sitzung ein KYC erfasst hat, POA-Felder nur, wenn sie einen POA erfasst hat, und KYB-Unternehmensfelder nur, wenn die Sitzung eine Prüfung des Unternehmensregisters enthält.
- **Teilaktualisierungen**: Nur die Felder, die Sie senden, werden geändert. Lassen Sie ein Feld weg, bleibt es unverändert. Senden Sie `null`, um einen `extra_fields`-Schlüssel zu entfernen.
- **Webhooks**: Eine erfolgreiche Aktualisierung löst `data.updated` mit `session_kind: "user"` oder `"business"` aus. Im Audit-Log der Sitzung wird festgehalten, welche konkreten Felder geändert wurden und wer die Änderung vorgenommen hat.## KYC-Identitätsdaten aktualisieren**`PATCH /v3/session/{sessionId}/update-data/`**Sie können jedes aus dem Ausweisdokument extrahierte Feld korrigieren. Graphbasierte Workflows mit mehreren Instanzen werden unterstützt: Über den optionalen Query-Parameter oder das Body-Feld `node_id` wählen Sie gezielt einen KYC-Datensatz aus, wenn eine einzelne Sitzung mehrere KYC-Schritte hat.### Änderbare Felder| Feld | Hinweise |
| - | - |
| `document_type` | ISO-Dokumentcode: `P` (Reisepass), `ID`, `DL`, `RP`. |
| `document_number` | Die aufgedruckte Dokumentnummer. |
| `personal_number` | Personen- bzw. Steuernummer, sofern auf dem Dokument aufgedruckt. |
| `date_of_birth` | ISO-8601-Datum. |
| `date_of_issue` / `expiration_date` | ISO-8601-Daten. |
| `issuing_state` | Ausstellungsland, ISO 3166-1 alpha-3. |
| `first_name` / `last_name` | `full_name` wird aus diesen beiden Feldern automatisch neu berechnet. |
| `gender` | `M`, `F` oder `X`, sofern vorhanden. |
| `nationality` | Freitext. |
| `marital_status` | Freitext. |
| `place_of_birth` | Freitext. |
| `address` | Freitextadresse aus dem Dokument. Löst erneute Geokodierung aus. |
| `parsed_address` | Strukturierte Adresse, siehe die verschachtelte Form unten. |
| `extra_fields` | Beliebige weitere Felder aus dem Ausweis (z. B. `blood_group`, `municipality`). Senden Sie `null` für einen Schlüssel, um ihn zu entfernen. |`parsed_address` akzeptiert nur diese verschachtelten Schlüssel: `address_type`, `city`, `region`, `street_1`, `street_2`, `postal_code`, `country` (ISO 3166-1 **alpha-2**).### Beispiel```bash theme={null}
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" }
  }'
```Für einen graphbasierten Workflow mit mehreren Instanzen fügen Sie `?node_id=feature_ocr_2` zur URL hinzu (oder übergeben `"node_id": "feature_ocr_2"` im Body), um gezielt einen KYC-Datensatz anzusprechen.## Adressnachweis-Daten (POA) aktualisieren**`PATCH /v3/session/{sessionId}/update-poa-data/`**Sie können Felder korrigieren, die aus einem Adressnachweis extrahiert wurden. Es gelten dieselben Statusbeschränkungen und Berechtigungen wie für KYC-Aktualisierungen. Auch hier wird `node_id` für Workflows mit mehreren Instanzen unterstützt.### Änderbare Felder| Feld | Hinweise |
| - | - |
| `issuing_state` | Land, das das Dokument ausgestellt hat, ISO 3166-1 alpha-3. |
| `document_type` | z. B. `utility_bill`, `bank_statement`, `lease_agreement`. |
| `document_language` | ISO-639-1-Sprachcode des Dokuments. |
| `issuer` | Versorgungsunternehmen, Bank, Vermieter usw. |
| `issue_date` | ISO-8601-Datum. |
| `poa_address` | Adresse, wie sie auf dem Dokument aufgedruckt ist (Freitext). Löst erneute Geokodierung aus. |
| `name_on_document` | Vollständiger Name, wie er auf dem Dokument aufgedruckt ist. |
| `poa_parsed_address` | Strukturierte Adresse, mit derselben verschachtelten Form wie `parsed_address` bei KYC. |
| `extra_fields` | Dokumentspezifische Felder: Bankdaten (`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` (Liste oder `null`). |### Beispiel```bash theme={null}
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"
    }
  }'
```## KYB-Unternehmensdaten aktualisieren**`PATCH /v3/session/{sessionId}/kyb/{companyUuid}/update-data/`**Korrigieren Sie die aus dem Register übernommenen Felder eines KYB-Unternehmens. Der Endpoint bearbeitet **sowohl** die kanonischen Unternehmensspalten **als auch** `registry_data`, sodass die Ansicht „Extracted from Registry“ in der Konsole Ihre Korrekturen anzeigt. `user_provided_data` (was der Endbenutzer im gehosteten Ablauf bestätigt hat) wird nicht verändert. `last_console_edit_at` wird gesetzt, und ein `data.updated`-Webhook wird mit `trigger: "console_registry_edit"` ausgelöst.### Voraussetzungen- **Berechtigung:** `write:businesses` (unterscheidet sich von der Berechtigung für KYC und Adressnachweis).
- Die `companyUuid` in der URL muss zur angegebenen `sessionId` gehören, andernfalls erhalten Sie einen 404-Fehler.
- Keine Statusprüfung der Sitzung: Die KYB-Unternehmensdaten können jederzeit korrigiert werden.### Änderbare Felder| Feld | Hinweise |
| - | - |
| `company_name` | Rechtlicher Name. |
| `registration_number` | Offizielle Registernummer. |
| `country_code` | Land der Gründung, ISO 3166-1 alpha-3. |
| `incorporation_date` / `registration_date` / `dissolution_date` | ISO-8601-Datumswerte. |
| `tax_number` | Steueridentifikationsnummer. |
| `legal_address` | Alias für `registered_address`: Der Wert wird in der kanonischen Spalte `registered_address` gespeichert. |
| `company_type` | Ltd / LLC / PLC / SA / GmbH / SL usw. |
| `registry_status` | `active`, `dissolved`, `struck_off`, `inactive` usw. |
| `verification_status` | `verified`, `failed`, `unknown`. |
| `alternative_names` | Handelsnamen, frühere Namen, DBAs. |
| `nature_of_business` | Kurzbeschreibung. |
| `registered_capital` | Autorisiertes bzw. ausgegebenes Kapital. |
| `website`, `email`, `phone` | Kontaktdaten. |
| `legal_entity_identifier` | LEI. |
| `location_of_registration` | Stadt bzw. Verwaltungseinheit. |
| `control_scheme` | Governance-Schema, sofern das Register es ausweist. |Ein weggelassenes Feld bleibt unverändert. Jedes gesendete Feld wird in die kanonische Spalte geschrieben (sofern eine existiert) und in `registry_data` zusammengeführt. Beim Zusammenführen in `registry_data` werden Datumswerte als ISO-8601-Strings serialisiert.### Beispiel```bash theme={null}
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"
  }'
```Antwort: das vollständige KYB-Unternehmensobjekt, mit derselben Struktur wie `registry_checks[].company` in der [Sitzungsentscheidung](https://docs.didit.me/de/sessions-api/retrieve-session.md#unternehmensverifizierung-kyb).## Eine Partei der Schlüsselpersonen überspringen**`PATCH /v3/session/{sessionId}/kyb/parties/{partyUuid}/`**Befreien Sie eine Partei der Schlüsselpersonen von der Verifizierung. Dies ist der Notausgang für eine Partei, deren eigene Prüfung nie abgeschlossen werden kann. Die übliche Ursache ist eine gelöschte untergeordnete Sitzung: Sobald die einzelne KYC-Sitzung, die einem UBO oder Geschäftsführer zugewiesen wurde, gelöscht ist, ist ihr Status eingefroren und kann nie einen endgültigen Status erreichen. Das KYB hat dann nichts mehr, was es aus `Awaiting User` herausbewegen könnte. Das Überspringen der Partei nimmt sie aus der Aggregation der Schlüsselpersonen heraus, die Prüfung wird sofort neu berechnet, und die Sitzung kann abgeschlossen sowie genehmigt oder abgelehnt werden.### Voraussetzungen- **Berechtigung:** `write:businesses`.
- Die `partyUuid` in der URL muss zur angegebenen `sessionId` gehören, andernfalls erhalten Sie einen 404-Fehler.
- **Nicht durch `allow_skip` eingeschränkt.** Diese Rollen-Einstellung begrenzt, was der Antragsteller beim Ausfüllen des gehosteten Bildschirms für Schlüsselpersonen überspringen darf. Dieser Endpoint ist die vom Betreiber vorgenommene Überschreibung und funktioniert daher auch bei Rollen, die der Antragsteller nicht hätte überspringen können.### Body| Feld | Typ | Hinweise |
| - | - | - |
| `is_skipped` | boolean | `true` befreit die Partei; `false` nimmt sie wieder in den Geltungsbereich auf, und die Prüfung wartet wieder auf sie. |`requires_verification` bleibt bewusst unverändert. Eine überschriebene Partei erscheint daher mit `requires_verification: true` **und** `is_skipped: true`. So zeigt der Datensatz weiterhin an, dass die Regeln eine Prüfung verlangt haben.### Beispiel```bash theme={null}
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 }'
```Antwort: die aktualisierte Partei, mit derselben Struktur wie ein Eintrag in `key_people_checks[].submitted.parties[]` in der [Sitzungsentscheidung](https://docs.didit.me/de/business-verification/response-schema.md#key_people_checks).Ein `data.updated`-Webhook wird mit `trigger: "console_key_people_skip"` ausgelöst.> [!NOTE]
>
> Eine Partei, deren untergeordnete Sitzung gelöscht wurde, ist in der Entscheidungs-Payload mit
> `kyc_session_deleted: true` (bzw. `kyb_sub_session_deleted: true` bei juristischen Personen) markiert.
> Ihre `kyc_session_url` bzw. `kyb_sub_session_url` wird als `null` zurückgegeben, weil der Link nicht mehr aufgelöst werden kann.
> Das Löschen einer untergeordneten Sitzung genehmigt die Partei nie allein: Die Prüfung der Schlüsselpersonen wechselt auf `In Review`, damit eine Person die Entscheidung trifft.## Was nach einer Aktualisierung passiert- **Webhook:** `data.updated` wird für die Sitzung ausgelöst, wobei die Payload das `session_kind` der Sitzung enthält (`"user"` oder `"business"`). Abonnieren Sie ihn einmal auf Ziel-Ebene und leiten Sie anhand von `session_kind` weiter.
- **Audit-Log:** Die Sitzung protokolliert genau, welche Felder sich geändert haben, die bisherigen und neuen Werte und (bei Aufrufen mit Benutzerauthentifizierung) die E-Mail-Adresse des Akteurs. Sichtbar im Events-Tab der Konsole.
- **Erneutes Geocoding der Adresse:** Bei KYC- und Adressnachweis-Aktualisierungen, die `address` bzw. `poa_address` ändern, führt Didit das Geocoding im Hintergrund erneut aus. Fehler werden stillschweigend ignoriert, sodass eine Aktualisierung nie wegen eines Geocoding-Problems fehlschlägt.
- **Erneutes AML-Screening:** KYC-Aktualisierungen, die Name, Geburtsdatum oder Staatsangehörigkeit ändern, können ein erneutes AML-Screening auslösen, sofern das AML-Screening für die Sitzung noch nicht abgeschlossen war. Die Ergebnisse erscheinen in der Sitzungsentscheidung.## Wann Sie diese Endpoints nicht verwenden sollten- **Gesamte Verifizierung erneut durchführen:** Muss der Kunde sein Ausweisfoto erneut aufnehmen oder ein Dokument erneut hochladen, verwenden Sie [update-status](https://docs.didit.me/de/sessions-api/update-status.md), um die Sitzung auf `Resubmitted` zu setzen.
- **Profilfelder der Entität User oder Business ändern:** Verwenden Sie [`PATCH /v3/users/{vendor_data}/`](https://docs.didit.me/de/management-api/users/update) oder [`PATCH /v3/businesses/{vendor_data}/`](https://docs.didit.me/de/management-api/businesses/update). Diese Endpoints aktualisieren Daten auf Entitätsebene, nicht Daten auf Sitzungsebene.
- **Details zu den Schlüsselpersonen bearbeiten:** Es gibt keine öffentliche API, um Name, Rollen oder Eigentumsverhältnisse einer Partei zu ändern; diese Daten werden über den gehosteten Ablauf übermittelt. Das einzige änderbare Feld ist `is_skipped` (siehe [Eine Partei der Schlüsselpersonen überspringen](#eine-partei-der-schlüsselpersonen-überspringen)).## Fehler| Status | Bedeutung |
| - | - |
| `401` | Fehlende oder ungültige Zugangsdaten. |
| `403` | Dem Aufrufer fehlt die erforderliche Berechtigung (`write:sessions` oder `write:businesses`). |
| `404` | Sitzung nicht gefunden, oder die Sitzung enthält den Datensatz nicht, den Sie aktualisieren möchten (kein KYC, kein POA, kein passendes Unternehmen, keine passende Partei oder eine Partei, die zu einer anderen Sitzung gehört). |
| `400` | Validierungsfehler: ungültiger Ländercode, unbekannter Schlüssel in `parsed_address`, `extra_fields` ist kein Objekt usw. |## Nächste Schritte> [card] [Sitzung abrufen](https://docs.didit.me/de/sessions-api/retrieve-session.md)
>
> Rufen Sie die vollständige Entscheidung ab, um die aktualisierten Felder zu sehen.> [card] [Status aktualisieren](https://docs.didit.me/de/sessions-api/update-status.md)
>
> Genehmigen, ablehnen oder eine Sitzung nach einer Datenkorrektur erneut öffnen.> [card] [Webhooks](https://docs.didit.me/de/integration/webhooks.md)
>
> Abonnieren Sie Webhook-Ereignisse vom Typ `data.updated`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.