> ## 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. # API статуса функции: одобрение и отклонение шага в Didit > Одобряйте, отклоняйте или отправляйте на проверку один шаг в Didit (OCR, проверка живости, сравнение лиц, AML, адрес, телефон) сразу или после сессии. Промпт для обновления статуса функции Скопировать промпт в буфер обмена \

\`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.`

\
Вставьте в ## Что это делаетСессия верификации состоит из отдельных **функций** (шагов): ID/OCR, Проверка живости, Сравнение лиц, AML, Подтверждение адреса, Проверка телефона и других. Этот endpoint позволяет задать статус **одного** из этих шагов: `Approved`, `Declined` или `In Review`.Используйте [update-status](https://docs.didit.me/ru/sessions-api/update-status.md), когда нужно одобрить, отклонить или снова открыть всю сессию целиком. Используйте **этот** endpoint, когда нужно зафиксировать решение только по одному шагу, например чтобы пометить шаг Сравнение лиц как `Declined` в вашем собственном процессе проверки.Сессия, у которой уже есть решение, его сохраняет: меняется только шаг. Если решения по сессии ещё нет, а её сценарий ждёт именно этот шаг, применение переопределения завершает шаг так же, как его обычное завершение. Сценарий продолжается, последующие шаги выполняются, а узел статуса может задать решение по сессии и отправить webhook `status.updated`.## Указание шага через `node_id`В сценариях на основе графа у каждого шага есть `node_id` (например, `feature_ocr_1`, `feature_liveness_1`, `feature_aml_1`). Их можно найти в [решении по сессии](https://docs.didit.me/ru/sessions-api/retrieve-session.md): каждая функция в решении V3 содержит свой `node_id`.Для **сценариев без графа (из одного шага)** у базовой функции нет идентификатора узла. Чтобы обратиться к ней, передайте буквальное значение `default` в `nodeId`. Поскольку ни один шаг такого сценария не имеет идентификатора узла, также передайте `feature_type` (например, `LIVENESS`, `AML` или `FACE_MATCH`), чтобы указать нужный шаг. Неизвестный `feature_type` возвращает `400`.## Ожидание завершения прохождения пользователемПо умолчанию переопределение применяется сразу. Если пользователь ещё проходит сценарий, это меняет шаг в работающем сценарии; тогда переопределение записывается с `forced: true`.Установите `defer_until_flow_finishes: true`, чтобы дождаться завершения. Пока сессия находится в статусе `Not Started`, `In Progress` или `Resubmitted` и пользователь не завершил прохождение, переопределение сохраняется как `pending_until_flow_finishes`. Оно применяется, когда пользователь завершает прохождение, после того как сценарий принимает собственное решение. Если сценарий по сессии уже завершён, переопределение применяется сразу в любом случае.Ожидающее переопределение отменяется вместо применения, если:- пользователь повторно проходит шаг до завершения (`check_changed`), - новое переопределение того же шага заменяет его (`replaced`), - сессия завершается до окончания сценария: прервана, истекла или по ней принято решение посреди сценария (`session_closed`), - вы отменяете его с помощью [Отмена переопределения функции](https://docs.didit.me/ru/sessions-api/cancel-feature-override.md) (`cancelled_by_reviewer`).В ответе поле `override` сообщает, что произошло: `state` принимает значение `applied` или `pending_until_flow_finishes`, а `applied_at` заполняется, когда переопределение применено. Верхнеуровневое поле `new_status` содержит сохранённый статус шага, поэтому пока переопределение ожидает, оно не меняется. Используйте [Список переопределений функций](https://docs.didit.me/ru/sessions-api/list-feature-overrides.md), чтобы увидеть все переопределения сессии и то, находится ли пользователь ещё в сценарии.## Поддержка KYC и KYBРаботает одинаково для сессий типа **Проверка пользователей (KYC)** и **Верификация бизнеса (KYB)**: Didit находит `sessionId` в обоих случаях. Поддерживаемые типы шагов: ID/OCR, Проверка живости, Сравнение лиц, NFC, AML, Подтверждение адреса, Проверка телефона, Проверка электронной почты, Проверка по базам данных, Анкеты, а также проверки реестра компаний, документов и ключевых лиц для KYB.> [!NOTE] > > Самостоятельные API-сессии (созданные через отдельные API верификации, `session_type = API`) не могут менять статусы отдельных функций: endpoint возвращает `400`.## Примеры> [tab] Одобрение шага > > ```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] Отклонение шага «Сравнение лиц» > > ```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] Сценарий из одного шага (узел по умолчанию) > > ```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] Ожидание завершения прохождения пользователем > > ```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 > }' > ```## Что происходит после обновления- **Webhook**: событие `data.updated` отправляется, когда переопределение применяется: сразу или по завершении прохождения. Пока оно ожидает или если отменено, ничего не отправляется. - **Активность**: каждое переопределение записывается в разделе **Активность** сессии со статусом `FEATURE_OVERRIDE_PENDING`, `FEATURE_OVERRIDE_APPLIED` или `FEATURE_OVERRIDE_CANCELLED`, с указанием инициатора (API-ключ, пользователь или система, когда ожидающее переопределение применяется). В записи запроса причиной служит ваш `comment`. В массиве `reviews` [решения по сессии](https://docs.didit.me/ru/sessions-api/retrieve-session.md) эти записи отображаются с `new_status: null`, а причина из вашего запроса находится в `comment`. - **Решение по сессии**: сессия, у которой уже есть решение, его сохраняет. Чтобы изменить итоговое решение, вызовите [update-status](https://docs.didit.me/ru/sessions-api/update-status.md) отдельно.## РазрешенияТребуется привилегия `write:sessions` с клиентским API-ключом (`x-api-key`) или заголовком авторизации пользователя. API-ключ с ограниченными правами должен иметь доступ на запись к решениям.## Связанные материалы- [Обновление статуса сессии](https://docs.didit.me/ru/sessions-api/update-status.md): изменить общее решение по сессии. - [Обновление статуса совпадения AML](https://docs.didit.me/ru/sessions-api/update-aml-hit-status.md): проверить отдельные совпадения AML. - [Получение сессии](https://docs.didit.me/ru/sessions-api/retrieve-session.md): получить решение (и `node_id` каждой функции). - [Вебхуки](https://docs.didit.me/ru/integration/webhooks.md): подписаться на `data.updated`. - [Список переопределений функций](https://docs.didit.me/ru/sessions-api/list-feature-overrides.md): все переопределения сессии и их состояние. - [Отмена переопределения функции](https://docs.didit.me/ru/sessions-api/cancel-feature-override.md): остановить ожидающее переопределение, чтобы оно не применилось. ## OpenAPI ````yaml ru/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 верификации личности. Аутентификация выполняется с помощью заголовка x-api-key. servers: - url: https://verification.didit.me security: [] tags: [] paths: /v3/session/{sessionId}/features/{nodeId}/update-status/: patch: tags: - Sessions summary: Обновить статус отдельной функции (шага) description: >- Устанавливает статус отдельной функции верификации (шага) в рамках сессии. Выберите функцию по её `nodeId` в графе сценария. В сценариях без графа, где у шагов нет узлов, используйте `default`, а также передайте `feature_type`, чтобы указать нужный шаг. Работает как для сессий Проверки пользователей (KYC), так и для сессий Верификации бизнеса (KYB), а также для каждого типа шагов: ID/OCR, Проверка живости, Сравнение лиц, NFC, AML-скрининг, Подтверждение адреса, Проверка телефона, Проверка электронной почты, Проверка по базам данных, Анкеты, а также проверок реестра компаний, документов и ключевых лиц для KYB. Этот endpoint **недоступен** для автономных сессий API (`session_type = API`). Параметр `new_status` должен принимать одно из значений: `Approved`, `Declined` или `In Review`, и должен отличаться от текущего статуса функции. **Когда применяется переопределение.** Без `defer_until_flow_finishes` (или со значением `false`) переопределение применяется немедленно, как и раньше; если пользователь всё ещё проходит сценарий, оно фиксируется как `forced`. При `defer_until_flow_finishes: true`, пока пользователь всё ещё проходит сценарий (сессия находится в статусе `Not Started`, `In Progress` или `Resubmitted` и ещё не завершена), переопределение сохраняется как `pending_until_flow_finishes` и применяется после завершения сценария, когда сценарий сформирует собственное решение. Для сессии, прохождение которой уже завершилось, оно в любом случае применяется немедленно. Ожидающее переопределение отменяется, если пользователь повторно выполняет этот шаг до завершения, если его заменяет более новое переопределение для той же проверки, если сессия выходит из процесса незавершённой (прервана, истекла или решение принято в середине процесса), либо при отмене через `POST /v3/session/{sessionId}/features/overrides/{overrideId}/cancel/`. Список переопределений сессии можно получить с помощью `GET /v3/session/{sessionId}/features/overrides/`. **Влияние на сессию.** Сессия, у которой уже есть решение, сохраняет его: меняется только проверка. Если у сессии ещё нет решения и её сценарий ожидает именно этот шаг, применение переопределения завершает шаг: сценарий переходит дальше, выполняются последующие шаги, а узел статуса может установить решение по сессии и инициировать отправку `status.updated`. **Webhook и активность.** Webhook `data.updated` отправляется при применении переопределения (сразу или после завершения процесса) и никогда не отправляется во время ожидания или при отмене. Каждое переопределение фиксируется в журнале активности сессии как `FEATURE_OVERRIDE_PENDING`, `FEATURE_OVERRIDE_APPLIED` или `FEATURE_OVERRIDE_CANCELLED` с указанием того, кто его выполнил; запись запроса содержит ваш `comment`. Выполняйте аутентификацию с помощью API-ключа (`x-api-key`) или пользовательского заголовка авторизации с правом `write:sessions`; API-ключу с ограниченной областью видимости требуется доступ на запись к решениям. operationId: patch_v3_session_update_feature_status parameters: - in: path name: sessionId required: true description: >- UUID сессии верификации. Принимает ID сессий как пользователей (KYC), так и компаний (KYB) — сервис сопоставляет ID для обоих типов сессий. schema: type: string format: uuid example: 11111111-2222-3333-4444-555555555555 - in: path name: nodeId required: true description: >- ID узла графа сценария для обновляемой функции (например, `feature_ocr_1`). Используйте строковое значение `default` для сценариев без графа (одношаговых), где у функции нет ID узла. 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: >- Целевой статус для этой функции. Должен отличаться от текущего значения. enum: - Approved - Declined - In Review example: Approved comment: type: string description: >- Необязательная текстовая заметка в свободной форме, фиксируемая в журнале проверки сессии при изменении этой функции. 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: >- На какой тип шага нацелено действие. Требуется в неграфовых сценариях (`nodeId` = `default`), где шаги не привязаны к общему узлу; в остальных случаях необязательно. Неизвестное значение возвращает `400`. example: LIVENESS defer_until_flow_finishes: type: boolean default: false description: >- Пока человек всё ещё проходит сценарий, сохранить переопределение как `pending_until_flow_finishes` и применить его после завершения сценария, а не сразу. Если параметр опущен или равен `false`, переопределение применяется сразу. В сессии, сценарий которой уже завершился, оно применяется сразу в любом случае. example: false examples: Apply Now: summary: Одобрить шаг верификации личности сразу value: new_status: Approved comment: Document manually verified by compliance. Wait For The Flow: summary: >- Одобрить шаг проверки живости, как только человек завершит сценарий value: new_status: Approved comment: Liveness retried with a reviewer present. defer_until_flow_finishes: true Non-graph Workflow: summary: >- Нацелить на шаг проверки живости сценария без узлов (nodeId = default) value: new_status: In Review feature_type: LIVENESS responses: '200': description: >- Переопределение сохранено. `new_status` представляет собой сохранённый статус проверки: запрошенный статус после применения переопределения либо неизменённый статус, пока ожидается завершение сценария. `override` указывает, что именно произошло. content: application/json: schema: type: object properties: session_id: type: string format: uuid node_id: type: string nullable: true description: >- Узел сценария для обновлённого шага или `null` для шага без узла (путь `default` в сценарии без графа). example: feature_ocr_1 feature_type: type: string description: >- Название модели обновленной функции (например, `KYC`, `Face`, `FaceMatch`, `AML`, `POA`). example: KYC new_status: type: string description: >- Сохранённый статус проверки: запрошенный после применения переопределения либо неизменённый, пока переопределение ожидает завершения сценария. example: Approved override: $ref: '#/components/schemas/FeatureStatusOverride' required: - session_id - node_id - feature_type - new_status - override examples: Applied: summary: Переопределение применилось немедленно 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, пока человек всё ещё находится в сценарии 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: >- Ошибка валидации. Возвращается, если `new_status` недействителен или не изменился, если `feature_type` неизвестен или если сессия является автономной API-сессией. content: application/json: examples: Same Status: summary: new_status совпадает с текущим статусом value: new_status: - The new status is the same as the current status. API Session: summary: Статус функции нельзя изменить для автономных сессий API value: - Cannot change feature status for API sessions. Unknown feature_type: summary: feature_type не является известным типом шага value: feature_type: - Unknown feature_type 'SELFIE'. '401': description: Срок действия API-ключа с ограниченной областью действия истёк. content: application/json: examples: Expired API Key: summary: >- API-ключ с ограниченной областью действия с истёкшим сроком действия value: detail: This API key has expired. '403': description: Отсутствуют учетные данные или недостаточно разрешений. content: application/json: examples: Invalid Credentials: summary: Отсутствует или недействителен x-api-key value: detail: >- Authentication credentials were not provided or are invalid. Missing Privilege: summary: У API-ключа отсутствует разрешение write:sessions value: detail: You do not have permission to perform this action. Scoped Key Without Access: summary: >- API-ключ с ограниченной областью действия без прав на запись решений value: detail: This API key has no write access to decisions. '404': description: Сессия не найдена, либо в ней нет функции с указанным `nodeId`. content: application/json: examples: Session Not Found: summary: Неизвестный session_id value: detail: Session not found. Feature Not Found: summary: Нет функции для этого 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: >- Одно переопределение статуса проверки (функции), выполненное с помощью `PATCH /v3/session/{sessionId}/features/{nodeId}/update-status/`: что оно меняет, применено ли оно или всё ещё ожидает завершения сценария пользователем, кто запросил и почему. 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: Идентификатор переопределения. Передайте его в endpoint отмены. example: 7c9e6679-7425-40de-944b-e07fc1f90ae7 node_id: type: string description: Узел сценария, указанный в запросе (`default` для шага без узла). example: feature_ocr_1 feature_type: type: string description: >- Параметр `feature_type`, переданный в запросе, или пустая строка, если он не был передан. example: '' feature_model: type: string description: >- Тип проверки, которая была переопределена, например `KYC`, `Face`, `AML` или `GeolocationCheck`. example: KYC previous_status: type: string enum: - Not Finished - Approved - Declined - In Review - Resub Requested description: Статус проверки на момент запроса переопределения. example: In Review new_status: type: string enum: - Approved - Declined - In Review description: Статус, устанавливаемый переопределением. example: Approved state: type: string enum: - applied - pending_until_flow_finishes - cancelled description: >- `applied`: проверка получила новый статус. `pending_until_flow_finishes`: переопределение ожидает и применяется, когда пользователь завершает прохождение сценария. `cancelled`: ожидание завершилось без применения (см. `cancel_reason`). example: applied forced: type: boolean description: >- `true`, если переопределение применилось немедленно, пока человек ещё находился в сценарии. example: false reason: type: string nullable: true description: Параметр `comment`, отправленный с запросом, или `null`. example: Document manually verified by compliance. requested_by: type: object nullable: true description: Кто запросил переопределение, или `null`, если это неизвестно. properties: email: type: string format: email nullable: true description: >- Электронная почта пользователя консоли или `null` для API-ключей и системы. example: reviewer@example.com name: type: string nullable: true description: Отображаемое имя запрашивающего или `null`. example: Alex Reviewer type: type: string enum: - CONSOLE_USER - API_KEY - SYSTEM description: >- Кто выполнил запрос: пользователь консоли, API-ключ или сам Didit. example: CONSOLE_USER requested_at: type: string format: date-time description: Время запроса переопределения. example: '2026-10-13T09:15:00Z' applied_at: type: string format: date-time nullable: true description: >- Когда проверка перешла в новый статус, или `null`, пока она ожидает или после её отмены. example: '2026-10-13T09:15:00Z' cancelled_at: type: string format: date-time nullable: true description: >- Когда переопределение в состоянии ожидания было отменено, или `null`. example: null cancel_reason: type: string nullable: true enum: - cancelled_by_reviewer - replaced - check_changed - session_closed - null description: >- Причина, по которой отложенное переопределение не было применено, или `null`. `cancelled_by_reviewer`: отменено через endpoint отмены. `replaced`: заменено более новым переопределением для той же проверки. `check_changed`: человек повторно прошёл проверку до завершения сценария. `session_closed`: сессия вышла из сценария до того, как человек завершил его (прервана, истекла или решение принято в процессе сценария). example: null securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: >- API-ключ вашего приложения из раздела «Разработчикам» -> «API-ключи» в Business Console. Основной ключ имеет полный доступ. Именованный ключ может иметь ограниченную область действия: без доступа, чтение или запись для каждого ресурса, ограничение определенными сценариями или одобренными сессиями, списком IP-адресов и сроком действия. 401 означает, что ключ неверен, отозван или его срок действия истек; 403 означает, что ключ не был передан, у ключа нет доступа к этому ресурсу или действию, либо запрос поступил с адреса вне его списка IP-адресов; 404 на маршруте сессии означает, что сессия не входит в сценарии или статусы ключа. Ключ без доступа к медиа получает URL изображений, видео и PDF как null, а ключ без прав на запись сессий получает ссылки на сессии и токены как null. См. https://docs.didit.me/console/api-keys. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.