> ## 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. # Funktionsstatus-API: Schritt genehmigen oder ablehnen > Didit-Schritte einzeln genehmigen oder ablehnen, z. B. OCR, Liveness, Gesichtsabgleich, AML, Adressnachweis, Telefon – sofort oder nach Abschluss. Prompt zum Aktualisieren des Funktionsstatus Prompt in die Zwischenablage kopieren \

\`Approve, decline, or move a SINGLE verification step (feature) of a Didit session to review, now or once the person finishes the flow.

Endpoint:
PATCH https://verification.didit.me/v3/session/{session_id}/features/{node_id}/update-status/

Authentication:
x-api-key (client API key) or a user-auth token. Privilege: write:sessions.

Path parameters:
\- session_id (UUID) — KYC or KYB; Didit resolves it against both session types.
\- node_id — the workflow graph node ID of the step (e.g. feature_ocr_1, feature_liveness_1, feature_aml_1). Use the literal "default" for non-graph (single-step) workflows where the step has no node ID.

Request body:
\- new_status (string, required): one of "Approved", "Declined", "In Review". Must differ from the step's current status.
\- comment (string, optional): your reason, saved in the session's activity and returned as the override's reason.
\- feature_type (string, optional): which kind of step to target, for example "LIVENESS", "AML", "FACE_MATCH", "ID_VERIFICATION". Needed when node_id is "default" (non-graph workflows, where steps have no node ID). An unknown value returns 400 { "feature_type": ["Unknown feature_type '...'."] }.
\- defer_until_flow_finishes (boolean, optional, default false): while the person is still in the flow, wait and apply the override when the flow finishes instead of at once.

When the override applies:
\- Omitted or false: it applies at once. If the person is still in the flow it is recorded as forced=true.
\- true while the person is still in the flow (session Not Started, In Progress or Resubmitted, and not finished): it is stored as "pending_until_flow_finishes" and applies when the flow finishes, after the flow reaches its own decision.
\- true after the flow ended: it applies at once.
\- A waiting override is cancelled instead when the person redoes the step before finishing, a newer override on the same step replaces it, the session leaves the flow unfinished (abandoned, expired, decided mid-flow), or you cancel it with POST /v3/session/{session_id}/features/overrides/{override_id}/cancel/.

Which steps this works on:
Every per-step feature record: OCR/ID, Liveness, Face Match, NFC, AML, Proof of Address (POA), Phone, Email, Database Validation, Questionnaire, and the KYB registry / documents / key-people checks.

Difference vs update-status:
\- update-status changes the OVERALL session decision (Approved/Declined/Resubmitted).
\- THIS endpoint changes ONE step's status. A session that already has a decision keeps it. If the session has no decision yet and its workflow is waiting on exactly this step, applying the override completes the step: the workflow moves on and a status node can set the session decision (and fire status.updated).

Not allowed:
\- Standalone API sessions (session_type = API) return 400.

curl example — approve the ID/OCR step:
curl -X PATCH https://verification.didit.me/v3/session//features/feature_ocr_1/update-status/ \
-H "x-api-key: " \
-H "Content-Type: application/json" \
-d '{ "new_status": "Approved", "comment": "Document manually verified" }'

Response: { session_id, node_id, feature_type, new_status, override }.
\- node_id is the step's workflow node, or null for a step without a node ("default" in a non-graph workflow).
\- new_status is the step's stored status: the requested one once the override applied, the unchanged one while it waits.
\- override: { id, node_id, feature_type, feature_model, previous_status, new_status, state ("applied" | "pending_until_flow_finishes" | "cancelled"), forced, reason, requested_by { email, name, type }, requested_at, applied_at, cancelled_at, cancel_reason }.

Side effects:
\- Fires a data.updated webhook when the override applies (at once, or when the flow finishes). Nothing is sent while it waits or when it is cancelled.
\- Records the override in the session's activity as FEATURE_OVERRIDE_PENDING, FEATURE_OVERRIDE_APPLIED or FEATURE_OVERRIDE_CANCELLED, with who made it; the request's entry carries your comment. In the decision's reviews array these entries appear with new_status null, and the request's entry has your reason in comment.

Failure modes:
\- 400: new_status invalid or unchanged, unknown feature_type, or the session is a standalone API session.
\- 401: the scoped API key has expired.
\- 403: missing credentials (a wrong, revoked or expired key gets 401), or the caller lacks write:sessions (a scoped key needs decisions write).
\- 404: session not found, or no feature has the given node_id.

Related: list overrides with GET /v3/session/{session_id}/features/overrides/ (see /sessions-api/list-feature-overrides); cancel a waiting one with POST /v3/session/{session_id}/features/overrides/{override_id}/cancel/ (see /sessions-api/cancel-feature-override).

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

\
Einfügen in ## Was dieser Endpoint bewirktEine Verifizierungssitzung besteht aus einzelnen **Funktionen** (Schritten): ID/OCR, Liveness, Gesichtsabgleich, AML, Adressnachweis, Telefon usw. Mit diesem Endpoint setzen Sie den Status **eines** dieser Schritte auf `Approved`, `Declined` oder `In Review`.Verwenden Sie [update-status](https://docs.didit.me/de/sessions-api/update-status.md), wenn Sie die gesamte Sitzung genehmigen, ablehnen oder erneut öffnen möchten. Verwenden Sie **diesen** Endpoint, wenn Sie nur eine Entscheidung für einen einzelnen Schritt festhalten möchten, zum Beispiel um den Schritt Gesichtsabgleich für Ihren eigenen Prüfablauf als `Declined` zu markieren.Eine Sitzung, die bereits eine Entscheidung hat, behält diese: Nur der Schritt ändert sich. Hat die Sitzung noch keine Entscheidung und wartet ihr Workflow genau auf diesen Schritt, schließt die Überschreibung den Schritt ab, so wie es der normale Abschluss täte. Der Workflow läuft weiter, spätere Schritte werden ausgeführt, und ein Status-Knoten kann die Sitzungsentscheidung setzen und einen Webhook `status.updated` auslösen.## Einen Schritt mit `node_id` ansteuernIn graphbasierten Workflows hat jeder Schritt eine `node_id` (zum Beispiel `feature_ocr_1`, `feature_liveness_1`, `feature_aml_1`). Sie finden diese in der [Sitzungsentscheidung](https://docs.didit.me/de/sessions-api/retrieve-session.md): Jede Funktion in einer V3-Entscheidung enthält ihre `node_id`.Bei **nicht graphbasierten (einschrittigen) Workflows** hat die zugrunde liegende Funktion keine Knoten-ID. Übergeben Sie den wörtlichen Wert `default` als `nodeId`, um sie anzusteuern. Da kein Schritt eines solchen Workflows eine Knoten-ID hat, übergeben Sie außerdem `feature_type` (zum Beispiel `LIVENESS`, `AML` oder `FACE_MATCH`), um anzugeben, welchen Schritt Sie meinen. Ein unbekannter `feature_type` liefert `400` zurück.## Bis zum Abschluss des Ablaufs wartenStandardmäßig wird die Überschreibung sofort angewendet. Befindet sich die Person noch im Ablauf, wird damit ein Schritt in einem noch laufenden Ablauf geändert; die Überschreibung wird dann mit `forced: true` erfasst.Setzen Sie `defer_until_flow_finishes: true`, um stattdessen zu warten. Solange die Sitzung `Not Started`, `In Progress` oder `Resubmitted` ist und die Person den Ablauf nicht abgeschlossen hat, wird die Überschreibung als `pending_until_flow_finishes` gespeichert. Sie wird angewendet, wenn die Person den Ablauf abschließt, nachdem der Ablauf seine eigene Entscheidung getroffen hat. Bei einer Sitzung, deren Ablauf bereits beendet ist, wird sie in beiden Fällen sofort angewendet.Eine wartende Überschreibung wird abgebrochen, anstatt angewendet zu werden, wenn:- die Person den Schritt vor dem Abschluss erneut durchläuft (`check_changed`), - eine neuere Überschreibung desselben Schritts sie ersetzt (`replaced`), - die Sitzung den Ablauf unvollständig verlässt: abgebrochen, abgelaufen oder mitten im Ablauf entschieden (`session_closed`), - Sie sie mit [Funktionsüberschreibung abbrechen](https://docs.didit.me/de/sessions-api/cancel-feature-override.md) abbrechen (`cancelled_by_reviewer`).Das Feld `override` in der Antwort gibt an, was passiert ist: `state` ist `applied` oder `pending_until_flow_finishes`, und `applied_at` ist gesetzt, sobald die Überschreibung angewendet wurde. Der Wert `new_status` auf oberster Ebene ist der gespeicherte Status des Schritts und bleibt daher unverändert, solange die Überschreibung wartet. Mit [Funktionsüberschreibungen auflisten](https://docs.didit.me/de/sessions-api/list-feature-overrides.md) sehen Sie jede Überschreibung einer Sitzung und ob sich die Person noch im Ablauf befindet.## Unterstützung für KYC und KYBFunktioniert identisch für Sitzungen der **Benutzerverifizierung (KYC)** und der **Unternehmensverifizierung (KYB)**. Didit löst die `sessionId` für beide auf. Unterstützte Schritttypen sind ID/OCR, Liveness, Gesichtsabgleich, NFC, AML, Adressnachweis, Telefon, E-Mail, Datenbankvalidierung, Fragebogen sowie die Prüfungen des KYB-Unternehmensregisters, der Dokumente und der Schlüsselpersonen.> [!NOTE] > > Eigenständige API-Sitzungen (also solche, die über die eigenständigen Verifizierungs-APIs erstellt wurden, `session_type = API`) können keine einzelnen Funktionsstatus geändert werden. Der Endpoint liefert in diesem Fall `400` zurück.## Beispiele> [tab] Einen Schritt genehmigen > > ```bash theme={null} > curl -X PATCH https://verification.didit.me/v3/session/4c5c7f3a-.../features/feature_ocr_1/update-status/ \ > -H "x-api-key: YOUR_API_KEY" \ > -H "Content-Type: application/json" \ > -d '{ > "new_status": "Approved", > "comment": "Document manually verified by compliance" > }' > ```> [tab] Den Gesichtsabgleich-Schritt ablehnen > > ```bash theme={null} > curl -X PATCH https://verification.didit.me/v3/session/4c5c7f3a-.../features/feature_face_match/update-status/ \ > -H "x-api-key: YOUR_API_KEY" \ > -H "Content-Type: application/json" \ > -d '{ > "new_status": "Declined" > }' > ```> [tab] Einschrittiger Workflow (Standard-Knoten) > > ```bash theme={null} > curl -X PATCH https://verification.didit.me/v3/session/4c5c7f3a-.../features/default/update-status/ \ > -H "x-api-key: YOUR_API_KEY" \ > -H "Content-Type: application/json" \ > -d '{ > "new_status": "In Review", > "feature_type": "LIVENESS" > }' > ```> [tab] Warten, bis die Person den Ablauf abschließt > > ```bash theme={null} > curl -X PATCH https://verification.didit.me/v3/session/4c5c7f3a-.../features/feature_liveness_1/update-status/ \ > -H "x-api-key: YOUR_API_KEY" \ > -H "Content-Type: application/json" \ > -d '{ > "new_status": "Approved", > "comment": "Liveness retried with a reviewer present", > "defer_until_flow_finishes": true > }' > ```## Was nach einer Aktualisierung passiert- **Webhook**: Ein Ereignis `data.updated` wird ausgelöst, sobald die Überschreibung angewendet wird, sofort oder wenn der Ablauf endet. Während sie wartet oder wenn sie abgebrochen wird, wird nichts gesendet. - **Aktivität**: Jede Überschreibung wird in der Aktivität der Sitzung als `FEATURE_OVERRIDE_PENDING`, `FEATURE_OVERRIDE_APPLIED` oder `FEATURE_OVERRIDE_CANCELLED` erfasst, mit dem Akteur (API-Schlüssel, Benutzer oder das System, wenn eine wartende Überschreibung angewendet wird). Der Eintrag der Anfrage enthält Ihren `comment` als Begründung. Im Array `reviews` der [Sitzungsentscheidung](https://docs.didit.me/de/sessions-api/retrieve-session.md) erscheinen diese Einträge mit `new_status: null`, und der Eintrag der Anfrage hat Ihre Begründung in `comment`. - **Sitzungsentscheidung**: Eine Sitzung, die bereits eine Entscheidung hat, behält sie. Um die endgültige Entscheidung zu ändern, rufen Sie separat [update-status](https://docs.didit.me/de/sessions-api/update-status.md) auf.## BerechtigungErforderlich ist die Berechtigung `write:sessions`, entweder mit einem Client-API-Schlüssel (`x-api-key`) oder mit einem Benutzer-Autorisierungsheader. Ein API-Schlüssel mit eingeschränktem Umfang benötigt Schreibzugriff auf Entscheidungen.## Verwandte Themen- [Sitzungsstatus aktualisieren](https://docs.didit.me/de/sessions-api/update-status.md): die gesamte Sitzungsentscheidung ändern. - [AML-Trefferstatus aktualisieren](https://docs.didit.me/de/sessions-api/update-aml-hit-status.md): einzelne AML-Treffer prüfen. - [Sitzung abrufen](https://docs.didit.me/de/sessions-api/retrieve-session.md): die Entscheidung abrufen (und die `node_id` jedes Schritts). - [Webhooks](https://docs.didit.me/de/integration/webhooks.md): `data.updated` abonnieren. - [Funktionsüberschreibungen auflisten](https://docs.didit.me/de/sessions-api/list-feature-overrides.md): jede Überschreibung einer Sitzung und ihr Status. - [Funktionsüberschreibung abbrechen](https://docs.didit.me/de/sessions-api/cancel-feature-override.md): verhindern, dass eine wartende Überschreibung angewendet wird. ## OpenAPI ````yaml de/openapi-25.json PATCH /v3/session/{sessionId}/features/{nodeId}/update-status/ openapi: 3.0.0 info: version: 3.0.0 title: Didit Verification API description: API für Ausweisverifizierung. Authentifizierung über den x-api-key-Header. servers: - url: https://verification.didit.me security: [] tags: [] paths: /v3/session/{sessionId}/features/{nodeId}/update-status/: patch: tags: - Sessions summary: Status einer einzelnen Funktion (Schritt) aktualisieren description: >- Setzen Sie den Status einer einzelnen Verifizierungsfunktion (Schritt) innerhalb einer Sitzung. Adressieren Sie die Funktion über deren Workflow-Graph-`nodeId`. Bei Workflows ohne Graph, deren Schritte keinen Knoten haben, verwenden Sie `default` und übergeben Sie zusätzlich `feature_type`, um anzugeben, welchen Schritt Sie meinen. Funktioniert sowohl für Sitzungen der Benutzerverifizierung (KYC) als auch der Unternehmensverifizierung (KYB) und für jeden Schritttyp: ID/OCR, Liveness, Gesichtsabgleich, NFC, AML, Adressnachweis, Telefon, E-Mail, Datenbankvalidierung, Fragebogen sowie die KYB-Prüfungen für Register / Dokumente / Schlüsselpersonen. Dieser Endpoint ist für Standalone-API-Sitzungen (`session_type = API`) **nicht** verfügbar. `new_status` muss `Approved`, `Declined` oder `In Review` sein und sich vom aktuellen Status der Funktion unterscheiden. **Wann das Überschreiben angewendet wird.** Ohne `defer_until_flow_finishes` (oder mit `false`) wird das Überschreiben wie gewohnt sofort angewendet; befindet sich die Person noch im Ablauf, wird es als `forced` protokolliert. Mit `defer_until_flow_finishes: true`, während sich die Person noch im Ablauf befindet (die Sitzung ist `Not Started`, `In Progress` oder `Resubmitted` und noch nicht abgeschlossen), wird das Überschreiben als `pending_until_flow_finishes` gespeichert und angewendet, sobald der Ablauf beendet ist, nachdem der Ablauf seine eigene Entscheidung getroffen hat. Bei einer Sitzung, deren Ablauf bereits beendet ist, wird es in jedem Fall sofort angewendet. Ein wartendes Überschreiben wird stattdessen storniert, wenn die Person den Schritt vor Abschluss wiederholt, wenn ein neueres Überschreiben für dieselbe Prüfung es ersetzt, wenn die Sitzung den Ablauf unvollendet verlässt (abgebrochen, abgelaufen oder mitten im Ablauf entschieden) oder wenn Sie es mit `POST /v3/session/{sessionId}/features/overrides/{overrideId}/cancel/` stornieren. Rufen Sie die Überschreibungen einer Sitzung mit `GET /v3/session/{sessionId}/features/overrides/` ab. **Auswirkung auf die Sitzung.** Eine Sitzung, die bereits eine Entscheidung hat, behält diese: Nur die Prüfung ändert sich. Wenn die Sitzung noch keine Entscheidung hat und ihr Workflow genau auf diesen Schritt wartet, schließt das Anwenden des Überschreibens den Schritt ab: Der Workflow wird fortgesetzt, spätere Schritte werden ausgeführt, und ein Status-Knoten kann die Sitzungsentscheidung festlegen und `status.updated` auslösen. **Webhooks und Aktivität.** Ein `data.updated`-Webhook wird ausgelöst, wenn das Überschreiben angewendet wird (sofort oder nach Abschluss des Ablaufs), niemals während es wartet oder storniert wird. Jedes Überschreiben wird in den Aktivitäten der Sitzung als `FEATURE_OVERRIDE_PENDING`, `FEATURE_OVERRIDE_APPLIED` oder `FEATURE_OVERRIDE_CANCELLED` zusammen mit dem Ersteller protokolliert; der Eintrag der Anfrage enthält Ihren `comment`. Authentifizieren Sie sich mit Ihrem API-Schlüssel (`x-api-key`) oder einem Benutzer-Autorisierungs-Header mit der Berechtigung `write:sessions`; ein API-Schlüssel mit Scopes benötigt Schreibzugriff auf Entscheidungen. operationId: patch_v3_session_update_feature_status parameters: - in: path name: sessionId required: true description: >- UUID der Verifizierungssitzung. Akzeptiert sowohl Benutzer- (KYC) als auch Unternehmens- (KYB) Sitzungs-IDs — der Dienst löst die ID über beide Sitzungstypen hinweg auf. schema: type: string format: uuid example: 11111111-2222-3333-4444-555555555555 - in: path name: nodeId required: true description: >- Workflow-Graph-Knoten-ID der zu aktualisierenden Funktion (beispielsweise `feature_ocr_1`). Verwenden Sie den literalen Wert `default` für Nicht-Graph-Workflows (Einzelschritt-Workflows), bei denen die Funktion keine Knoten-ID besitzt. schema: type: string example: feature_ocr_1 requestBody: required: true content: application/json: schema: type: object required: - new_status properties: new_status: type: string description: >- Zielstatus für diese Funktion. Muss vom aktuellen Wert abweichen. enum: - Approved - Declined - In Review example: Approved comment: type: string description: >- Optionale Freitextnotiz, die im Prüfungsprotokoll der Sitzung für diese Funktionsänderung aufgezeichnet wird. example: Document manually verified by compliance. feature_type: type: string enum: - ID_VERIFICATION - OCR - OCR_BACK - NFC - LIVENESS - FACE - AGE_ESTIMATION - AGE_VERIFICATION - FACE_SEARCH - FACE_MATCH - IP_ANALYSIS - AML - PHONE - PHONE_VERIFICATION - EMAIL - EMAIL_VERIFICATION - POA - PROOF_OF_ADDRESS - DATABASE_VALIDATION - DATA_VALIDATION - QUESTIONNAIRE - DOCUMENT_AI - KYB_REGISTRY - KYB_DOCUMENTS - KYB_KEY_PEOPLE - BANK_VERIFICATION - GEOLOCATION description: >- Auf welche Art von Schritt abgezielt werden soll. Erforderlich bei Nicht-Graph-Workflows (`nodeId` = `default`), bei denen die Schritte keinen gemeinsamen Knoten haben; andernfalls optional. Ein unbekannter Wert gibt `400` zurück. example: LIVENESS defer_until_flow_finishes: type: boolean default: false description: >- Solange sich die Person noch im Ablauf befindet, wird die Überschreibung als `pending_until_flow_finishes` gespeichert und angewendet, sobald der Ablauf beendet ist, anstatt sofort. Wenn weggelassen oder `false`, wird die Überschreibung sofort angewendet. Bei einer Sitzung, deren Ablauf bereits beendet ist, wird sie in jedem Fall sofort angewendet. example: false examples: Apply Now: summary: Den Ausweisschritt sofort genehmigen value: new_status: Approved comment: Document manually verified by compliance. Wait For The Flow: summary: >- Den Liveness-Schritt genehmigen, sobald die Person den Ablauf beendet hat value: new_status: Approved comment: Liveness retried with a reviewer present. defer_until_flow_finishes: true Non-graph Workflow: summary: >- Auf den Liveness-Schritt eines Workflows ohne Knoten abzielen (nodeId = default) value: new_status: In Review feature_type: LIVENESS responses: '200': description: >- Der Override wurde erfasst. `new_status` ist der gespeicherte Status der Prüfung: der angeforderte, sobald der Override angewendet wurde, der unveränderte, während er auf den Abschluss des Ablaufs wartet. `override` gibt an, was eingetreten ist. content: application/json: schema: type: object properties: session_id: type: string format: uuid node_id: type: string nullable: true description: >- Der Workflow-Knoten des aktualisierten Schritts oder `null` für einen Schritt ohne Knoten (der `default`-Pfad in einem Workflow ohne Graph). example: feature_ocr_1 feature_type: type: string description: >- Modellname der aktualisierten Funktion (z. B. `KYC`, `Face`, `FaceMatch`, `AML`, `POA`). example: KYC new_status: type: string description: >- Der gespeicherte Status der Überprüfung: der angefragte, sobald der Override angewendet wurde; der unveränderte, während der Override auf den Abschluss des Workflows wartet. example: Approved override: $ref: '#/components/schemas/FeatureStatusOverride' required: - session_id - node_id - feature_type - new_status - override examples: Applied: summary: Der Override wurde sofort angewendet value: session_id: 3fa85f64-5717-4562-b3fc-2c963f66afa6 node_id: feature_ocr_1 feature_type: KYC new_status: Approved override: id: 7c9e6679-7425-40de-944b-e07fc1f90ae7 node_id: feature_ocr_1 feature_type: '' feature_model: KYC previous_status: In Review new_status: Approved state: applied forced: false reason: Document manually verified by compliance. requested_by: email: reviewer@example.com name: Alex Reviewer type: CONSOLE_USER requested_at: '2026-10-13T09:15:00Z' applied_at: '2026-10-13T09:15:00Z' cancelled_at: null cancel_reason: null Waiting For The Flow: summary: >- defer_until_flow_finishes, während sich die Person noch im Ablauf befindet value: session_id: 3fa85f64-5717-4562-b3fc-2c963f66afa6 node_id: feature_liveness_1 feature_type: Face new_status: Declined override: id: 9b2f4c1e-8d3a-4e5f-a6b7-c8d9e0f1a2b3 node_id: feature_liveness_1 feature_type: '' feature_model: Face previous_status: Declined new_status: Approved state: pending_until_flow_finishes forced: false reason: Liveness retried with a reviewer present. requested_by: email: reviewer@example.com name: Alex Reviewer type: CONSOLE_USER requested_at: '2026-10-13T09:15:00Z' applied_at: null cancelled_at: null cancel_reason: null '400': description: >- Validierungsfehler. Wird zurückgegeben, wenn `new_status` ungültig oder unverändert ist, wenn `feature_type` unbekannt ist oder wenn die Sitzung eine eigenständige API-Sitzung ist. content: application/json: examples: Same Status: summary: new_status entspricht dem aktuellen Status value: new_status: - The new status is the same as the current status. API Session: summary: >- Funktionsstatus kann bei Standalone-API-Sitzungen nicht geändert werden value: - Cannot change feature status for API sessions. Unknown feature_type: summary: feature_type ist kein bekannter Schritttyp value: feature_type: - Unknown feature_type 'SELFIE'. '401': description: >- Der API-Schlüssel mit eingeschränktem Geltungsbereich ist abgelaufen. content: application/json: examples: Expired API Key: summary: >- API-Schlüssel mit eingeschränktem Berechtigungsumfang nach Ablaufdatum value: detail: This API key has expired. '403': description: Fehlende Anmeldedaten oder unzureichende Berechtigungen. content: application/json: examples: Invalid Credentials: summary: Fehlender oder ungültiger x-api-key value: detail: >- Authentication credentials were not provided or are invalid. Missing Privilege: summary: Dem API-Schlüssel fehlt die Berechtigung write:sessions value: detail: You do not have permission to perform this action. Scoped Key Without Access: summary: >- API-Schlüssel mit eingeschränktem Berechtigungsumfang ohne Schreibzugriff auf Entscheidungen value: detail: This API key has no write access to decisions. '404': description: >- Die Sitzung wurde nicht gefunden, oder sie besitzt keine Funktion mit der angegebenen `nodeId`. content: application/json: examples: Session Not Found: summary: Unbekannte session_id value: detail: Session not found. Feature Not Found: summary: Keine Funktion für diese node_id value: detail: >- No feature found with node_id 'feature_ocr_1' in this session. security: - ApiKeyAuth: [] x-codeSamples: - lang: curl label: curl source: |- curl -X PATCH \ https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/features/feature_ocr_1/update-status/ \ -H 'x-api-key: YOUR_API_KEY' \ -H 'Content-Type: application/json' \ -d '{ "new_status": "Approved", "comment": "Document manually verified by compliance." }' - lang: python label: Python source: |- from didit import Didit # Reads DIDIT_API_KEY. client = Didit() result = client.sessions.update_feature_status( "11111111-2222-3333-4444-555555555555", "feature_ocr_1", new_status="Approved", comment="Document manually verified by compliance.", ) print(result) - lang: javascript label: Node.js source: |- import Didit from "@didit-protocol/sdk-node"; // Reads DIDIT_API_KEY. const didit = new Didit(); const result = await didit.sessions.updateFeatureStatus( "11111111-2222-3333-4444-555555555555", "feature_ocr_1", { new_status: "Approved", comment: "Document manually verified by compliance.", }, ); console.log(result); - lang: go label: Go source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Sessions.UpdateFeatureStatus(ctx, \"11111111-2222-3333-4444-555555555555\", \"feature_ocr_1\", didit.SessionsUpdateFeatureStatusParams{\n\tNewStatus: \"Approved\",\n\tComment: didit.String(\"Document manually verified by compliance.\"),\n})\nif err != nil {\n\tlog.Fatal(err)\n}\nfmt.Printf(\"%+v\\n\", result)" - lang: java label: Java source: >- import me.didit.Didit; import me.didit.types.SessionsUpdateFeatureStatusParams; // Reads DIDIT_API_KEY. Didit client = new Didit(); var result = client.sessions().updateFeatureStatus("11111111-2222-3333-4444-555555555555", "feature_ocr_1", SessionsUpdateFeatureStatusParams.builder() .newStatus(SessionsUpdateFeatureStatusParams.NewStatus.of("Approved")) .comment("Document manually verified by compliance.") .build()); System.out.println(result); - lang: php label: PHP source: >- sessions->updateFeatureStatus('11111111-2222-3333-4444-555555555555', 'feature_ocr_1', [ 'new_status' => 'Approved', 'comment' => 'Document manually verified by compliance.', ]); print_r($result->toArray()); - lang: ruby label: Ruby source: |- require "didit" # Reads DIDIT_API_KEY. didit = Didit::Client.new result = didit.sessions.update_feature_status( "11111111-2222-3333-4444-555555555555", "feature_ocr_1", new_status: "Approved", comment: "Document manually verified by compliance." ) puts result.to_h - lang: csharp label: .NET source: >- using System; using System.Text.Json; using Didit; // Reads DIDIT_API_KEY. using var client = new DiditClient(); var result = await client.Sessions.UpdateFeatureStatusAsync("11111111-2222-3333-4444-555555555555", "feature_ocr_1", new SessionsUpdateFeatureStatusParams { NewStatus = "Approved", Comment = "Document manually verified by compliance.", }); Console.WriteLine(JsonSerializer.Serialize(result)); components: schemas: FeatureStatusOverride: type: object description: >- Eine Überschreibung eines Prüfungs- bzw. Funktionsstatus, vorgenommen mit `PATCH /v3/session/{sessionId}/features/{nodeId}/update-status/`: was geändert wird, ob sie angewendet wurde oder noch darauf wartet, dass die Person den Flow abschließt, wer die Anfrage gestellt hat und warum. required: - id - node_id - feature_type - feature_model - previous_status - new_status - state - forced - reason - requested_by - requested_at - applied_at - cancelled_at - cancel_reason properties: id: type: string format: uuid description: Kennung des Overrides. Übergeben Sie sie an den Cancel-Endpoint. example: 7c9e6679-7425-40de-944b-e07fc1f90ae7 node_id: type: string description: >- Der in der Anfrage angegebene Workflow-Knoten (`default` für einen Schritt ohne Knoten). example: feature_ocr_1 feature_type: type: string description: >- Der von der Anfrage übergebene `feature_type` oder eine leere Zeichenkette, wenn keiner übergeben wurde. example: '' feature_model: type: string description: >- Die Art der Prüfung, die überschrieben wurde, beispielsweise `KYC`, `Face`, `AML` oder `GeolocationCheck`. example: KYC previous_status: type: string enum: - Not Finished - Approved - Declined - In Review - Resub Requested description: Der Status der Überprüfung zum Zeitpunkt der Anfrage des Overrides. example: In Review new_status: type: string enum: - Approved - Declined - In Review description: Der Status, den die Überschreibung festlegt. example: Approved state: type: string enum: - applied - pending_until_flow_finishes - cancelled description: >- `applied`: Die Prüfung hat den neuen Status. `pending_until_flow_finishes`: Das Override wartet und greift, wenn die Person den Ablauf beendet. `cancelled`: Es hat gewartet und wurde nie angewendet (siehe `cancel_reason`). example: applied forced: type: boolean description: >- `true`, wenn die Überschreibung sofort angewendet wurde, während die Person sich noch im Ablauf befand. example: false reason: type: string nullable: true description: Der mit der Anfrage gesendete `comment` oder `null`. example: Document manually verified by compliance. requested_by: type: object nullable: true description: >- Wer die Übersteuerung angefordert hat, oder `null`, wenn dies nicht bekannt ist. properties: email: type: string format: email nullable: true description: >- E-Mail des Console-Benutzers oder `null` für API-Schlüssel und das System. example: reviewer@example.com name: type: string nullable: true description: Anzeigename des Anfragenden oder `null`. example: Alex Reviewer type: type: string enum: - CONSOLE_USER - API_KEY - SYSTEM description: >- Wer die Anfrage gestellt hat: ein Benutzer der Konsole, ein API-Schlüssel oder Didit selbst. example: CONSOLE_USER requested_at: type: string format: date-time description: Wann die Übersteuerung angefordert wurde. example: '2026-10-13T09:15:00Z' applied_at: type: string format: date-time nullable: true description: >- Wann die Überprüfung den neuen Status angenommen hat, oder `null`, während sie wartet oder sobald sie storniert wurde. example: '2026-10-13T09:15:00Z' cancelled_at: type: string format: date-time nullable: true description: Wann ein wartender Override abgebrochen wurde, oder `null`. example: null cancel_reason: type: string nullable: true enum: - cancelled_by_reviewer - replaced - check_changed - session_closed - null description: >- Warum ein wartendes Override nie angewendet wurde, oder `null`. `cancelled_by_reviewer`: über den Abbrechen-Endpoint storniert. `replaced`: ein neueres Override für denselben Check hat es ersetzt. `check_changed`: die Person hat die Prüfung vor dem Abschluss des Ablaufs wiederholt. `session_closed`: die Sitzung wurde beendet, bevor die Person den Ablauf abgeschlossen hat (abgebrochen, abgelaufen oder mitten im Ablauf entschieden). example: null securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: >- Der API-Schlüssel Ihrer Anwendung, aus Entwickler -> API-Schlüssel in der Business Console. Der Primärschlüssel hat Vollzugriff. Ein benannter Schlüssel kann im Geltungsbereich eingeschränkt werden: keine, Lese- oder Schreibberechtigung pro Ressource, beschränkt auf bestimmte Workflows oder genehmigte Sitzungen, auf eine Liste von IP-Adressen und auf ein Ablaufdatum. 401 bedeutet, dass der Schlüssel falsch, widerrufen oder abgelaufen ist; 403 bedeutet, dass kein Schlüssel gesendet wurde, der Schlüssel keinen Zugriff auf diese Ressource oder Aktion hat oder die Anfrage von einer Adresse außerhalb seiner IP-Liste stammte; 404 bei einer Sitzungsroute bedeutet, dass die Sitzung außerhalb der Workflows oder Status des Schlüssels liegt. Ein Schlüssel ohne Medienzugriff erhält Bild-, Video- und PDF-URLs als null, und ein Schlüssel ohne Schreibberechtigung für Sitzungen erhält Sitzungslinks und Token als null. Siehe https://docs.didit.me/console/api-keys. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.