> ## 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. # Atualizar status de recurso na API: aprovar ou recusar > Com a API da Didit, aprove, recuse ou envie para revisão uma etapa da verificação (OCR, Liveness, Face Match, AML, POA…) agora ou ao fim do fluxo. Prompt para atualizar o status de um recurso Copiar o prompt para a área de transferência \

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

\
Colar em ## O que isto fazUma sessão de verificação é composta por **recursos** individuais (etapas): ID/OCR, Prova de vida, Correspondência facial, AML, Comprovante de endereço, Telefone e assim por diante. Este endpoint permite definir o status de **uma** dessas etapas como `Approved`, `Declined` ou `In Review`.Use [update-status](https://docs.didit.me/pt-br/sessions-api/update-status.md) quando quiser aprovar, recusar ou reabrir a sessão inteira. Use **este** endpoint quando quiser registrar uma decisão em apenas uma etapa, por exemplo para marcar a etapa de Correspondência facial como `Declined` no seu próprio fluxo de revisão.Uma sessão que já tem uma decisão a mantém: apenas a etapa muda. Se a sessão ainda não tem decisão e o fluxo de verificação (workflow) está aguardando exatamente esta etapa, aplicar a substituição conclui a etapa, como ocorreria se ela fosse concluída normalmente. O fluxo avança, as etapas seguintes são executadas, e um nó de status pode definir a decisão da sessão e disparar um webhook `status.updated`.## Como direcionar uma etapa com `node_id`Em fluxos baseados em grafo, cada etapa tem um `node_id` (por exemplo `feature_ocr_1`, `feature_liveness_1`, `feature_aml_1`). Você encontra esses valores na [decisão da sessão](https://docs.didit.me/pt-br/sessions-api/retrieve-session.md): cada recurso em uma decisão V3 traz o seu `node_id`.Em **fluxos sem grafo (de etapa única)**, o recurso subjacente não tem ID de nó. Passe o valor literal `default` como `nodeId` para direcioná-lo. Como nenhuma etapa desse tipo de fluxo tem ID de nó, passe também `feature_type` (por exemplo `LIVENESS`, `AML` ou `FACE_MATCH`) para indicar a etapa desejada. Um `feature_type` desconhecido retorna `400`.## Aguardar até que a pessoa conclua o fluxoPor padrão, a sobreposição é aplicada imediatamente. Se a pessoa ainda estiver percorrendo o fluxo, isso altera uma etapa de um fluxo que ainda está em execução; nesse caso, a sobreposição é registrada com `forced: true`.Defina `defer_until_flow_finishes: true` para aguardar. Enquanto a sessão estiver `Not Started`, `In Progress` ou `Resubmitted` e a pessoa não tiver concluído, a sobreposição fica armazenada como `pending_until_flow_finishes`. Ela é aplicada quando a pessoa conclui o fluxo, depois que o fluxo chega à sua própria decisão. Em uma sessão cujo fluxo já terminou, ela é aplicada imediatamente em qualquer caso.Uma sobreposição em espera é cancelada em vez de aplicada quando:- a pessoa refaz a etapa antes de concluir (`check_changed`), - uma sobreposição mais recente na mesma etapa a substitui (`replaced`), - a sessão é encerrada sem que o fluxo seja concluído: abandonada, expirada ou decidida no meio do fluxo (`session_closed`), - você a cancela com [Cancel Feature Override](https://docs.didit.me/pt-br/sessions-api/cancel-feature-override.md) (`cancelled_by_reviewer`).O `override` da resposta informa o que aconteceu: `state` é `applied` ou `pending_until_flow_finishes`, e `applied_at` é preenchido assim que a sobreposição é aplicada. O `new_status` de nível superior é o status armazenado da etapa, por isso permanece inalterado enquanto a sobreposição aguarda. Use [List Feature Overrides](https://docs.didit.me/pt-br/sessions-api/list-feature-overrides.md) para ver todas as sobreposições de uma sessão e se a pessoa ainda está no fluxo.## Suporte a KYC e KYBFunciona da mesma forma para sessões de **Verificação de Usuário (KYC)** e **Verificação de Empresas (KYB)**: a Didit localiza o `sessionId` nos dois tipos. Os tipos de etapa compatíveis incluem ID/OCR, Prova de vida, Correspondência facial, NFC, AML, Comprovante de endereço, Telefone, E-mail, Validação de banco de dados, Questionário e as verificações de registro, documentos e pessoas-chave do KYB.> [!NOTE] > > Sessões de API independentes (criadas pelas APIs de verificação independentes, `session_type = API`) não permitem alterar o status de recursos individuais: o endpoint retorna `400`.## Exemplos> [tab] Aprovar uma etapa > > ```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] Recusar a etapa de Correspondência facial > > ```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] Fluxo de etapa única (nó padrão) > > ```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] Aguardar a pessoa concluir o fluxo > > ```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 > }' > ```## O que acontece após uma atualização- **Webhook**: um evento `data.updated` é disparado quando a sobreposição é aplicada, imediatamente ou quando o fluxo termina. Nada é enviado enquanto ela aguarda nem quando é cancelada. - **Atividade**: toda sobreposição é registrada na atividade da sessão como `FEATURE_OVERRIDE_PENDING`, `FEATURE_OVERRIDE_APPLIED` ou `FEATURE_OVERRIDE_CANCELLED`, com o autor (chave de API, usuário ou o sistema, quando uma sobreposição em espera é aplicada). A entrada da requisição traz o seu `comment` como motivo. No array `reviews` da [decisão da sessão](https://docs.didit.me/pt-br/sessions-api/retrieve-session.md), essas entradas aparecem com `new_status: null`, e a entrada da requisição tem o seu motivo em `comment`. - **Decisão da sessão**: uma sessão que já tem uma decisão a mantém. Para alterar a decisão final, chame [update-status](https://docs.didit.me/pt-br/sessions-api/update-status.md) separadamente.## PermissãoExige o privilégio `write:sessions`, usando uma chave de API de cliente (`x-api-key`) ou um cabeçalho de autorização de usuário. Uma chave de API com escopo precisa de acesso de escrita a decisões.## Relacionados- [Atualizar o status da sessão](https://docs.didit.me/pt-br/sessions-api/update-status.md): altere a decisão geral da sessão. - [Atualizar o status de uma correspondência AML](https://docs.didit.me/pt-br/sessions-api/update-aml-hit-status.md): revise correspondências AML individuais. - [Recuperar sessão](https://docs.didit.me/pt-br/sessions-api/retrieve-session.md): obtenha a decisão (e o `node_id` de cada recurso). - [Webhooks](https://docs.didit.me/pt-br/integration/webhooks.md): assine o evento `data.updated`. - [List Feature Overrides](https://docs.didit.me/pt-br/sessions-api/list-feature-overrides.md): todas as sobreposições de uma sessão e o estado de cada uma. - [Cancel Feature Override](https://docs.didit.me/pt-br/sessions-api/cancel-feature-override.md): impeça que uma sobreposição em espera seja aplicada. ## OpenAPI ````yaml pt-br/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 de verificação de identidade. Autentique-se com o cabeçalho x-api-key. servers: - url: https://verification.didit.me security: [] tags: [] paths: /v3/session/{sessionId}/features/{nodeId}/update-status/: patch: tags: - Sessions summary: Atualizar o status de um recurso individual (etapa) description: >- Define o status de um único recurso de verificação (etapa) em uma sessão. Identifique o recurso pelo `nodeId` do grafo do fluxo. Em fluxos que não usam grafo, cujas etapas não têm nó, use `default` e passe também `feature_type` para indicar a qual etapa você se refere. Funciona tanto para sessões de Verificação de usuários (KYC) quanto de Verificação de empresas (KYB) e para todos os tipos de etapa: ID/OCR, Prova de vida, Correspondência facial, NFC, AML, Comprovante de endereço, Telefone, E-mail, Validação de banco de dados, Questionário e as verificações de registro / documentos / pessoas-chave do KYB. Este endpoint **não** está disponível para sessões de API independentes (`session_type = API`). `new_status` deve ser `Approved`, `Declined` ou `In Review` e deve ser diferente do status atual do recurso. **Quando a substituição é aplicada.** Sem `defer_until_flow_finishes` (ou com `false`), a substituição é aplicada imediatamente, como sempre foi; quando a pessoa ainda está no fluxo, ela é registrada como `forced`. Com `defer_until_flow_finishes: true` enquanto a pessoa ainda está no fluxo (a sessão está `Not Started`, `In Progress` ou `Resubmitted` e não foi concluída), a substituição é armazenada como `pending_until_flow_finishes` e é aplicada quando o fluxo termina, depois que o fluxo chega à sua própria decisão. Em uma sessão cujo fluxo já terminou, ela é aplicada imediatamente em qualquer caso. Uma substituição em espera é cancelada, em vez de aplicada, quando a pessoa refaz a etapa correspondente antes de terminar, quando uma substituição mais recente na mesma verificação a substitui, quando a sessão sai do fluxo sem concluí-lo (abandonada, expirada ou decidida no meio do fluxo) ou quando você a cancela com `POST /v3/session/{sessionId}/features/overrides/{overrideId}/cancel/`. Liste as substituições de uma sessão com `GET /v3/session/{sessionId}/features/overrides/`. **Efeito na sessão.** Uma sessão que já tem uma decisão a mantém: apenas a verificação muda. Quando a sessão ainda não tem decisão e o fluxo está aguardando exatamente esta etapa, aplicar a substituição conclui a etapa: o fluxo avança, as etapas seguintes são executadas e um nó de status pode definir a decisão da sessão e disparar `status.updated`. **Webhooks e atividade.** Um webhook `data.updated` é disparado quando a substituição é aplicada (imediatamente ou quando o fluxo termina), nunca enquanto ela aguarda nem quando é cancelada. Toda substituição é registrada na atividade da sessão como `FEATURE_OVERRIDE_PENDING`, `FEATURE_OVERRIDE_APPLIED` ou `FEATURE_OVERRIDE_CANCELLED`, com quem a fez; a entrada da requisição inclui o seu `comment`. Autentique-se com sua chave de API (`x-api-key`) ou com um cabeçalho de autorização de usuário que tenha o privilégio `write:sessions`; uma chave de API com escopo precisa de acesso de escrita a decisões. operationId: patch_v3_session_update_feature_status parameters: - in: path name: sessionId required: true description: >- UUID da sessão de verificação. Aceita IDs de sessão tanto de usuário (KYC) quanto de empresa (KYB): o serviço resolve o ID entre os dois tipos de sessão. schema: type: string format: uuid example: 11111111-2222-3333-4444-555555555555 - in: path name: nodeId required: true description: >- ID do nó do grafo do fluxo do recurso a ser atualizado (por exemplo, `feature_ocr_1`). Use o valor literal `default` para fluxos sem grafo (de etapa única), nos quais o recurso não tem ID de nó. 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: >- Status de destino para este recurso. Deve ser diferente do valor atual. enum: - Approved - Declined - In Review example: Approved comment: type: string description: >- Nota opcional em texto livre registrada no histórico de revisão da sessão para esta alteração de recurso. 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: >- Qual tipo de etapa visar. Necessário em fluxos que não são de grafo (`nodeId` = `default`), em que as etapas não têm nó próprio; opcional nos demais casos. Um valor desconhecido retorna `400`. example: LIVENESS defer_until_flow_finishes: type: boolean default: false description: >- Enquanto a pessoa ainda estiver no fluxo, armazena a substituição como `pending_until_flow_finishes` e a aplica quando o fluxo terminar, em vez de imediatamente. Se omitido ou `false`, a substituição é aplicada imediatamente. Em uma sessão cujo fluxo já terminou, ela é aplicada imediatamente em qualquer caso. example: false examples: Apply Now: summary: Aprovar a etapa de identidade imediatamente value: new_status: Approved comment: Document manually verified by compliance. Wait For The Flow: summary: >- Aprovar a etapa de prova de vida assim que a pessoa concluir o fluxo value: new_status: Approved comment: Liveness retried with a reviewer present. defer_until_flow_finishes: true Non-graph Workflow: summary: >- Direcionar a etapa de prova de vida de um fluxo sem nós (nodeId = default) value: new_status: In Review feature_type: LIVENESS responses: '200': description: >- A substituição foi registrada. `new_status` é o status da verificação conforme armazenado: o solicitado, depois que a substituição foi aplicada, ou o inalterado, enquanto ela aguarda a conclusão do fluxo. `override` indica o que aconteceu. content: application/json: schema: type: object properties: session_id: type: string format: uuid node_id: type: string nullable: true description: >- O nó do fluxo da etapa atualizada, ou `null` para uma etapa sem nó (o caminho `default` em um fluxo que não é baseado em grafo). example: feature_ocr_1 feature_type: type: string description: >- Nome do modelo do recurso atualizado (por exemplo, `KYC`, `Face`, `FaceMatch`, `AML`, `POA`). example: KYC new_status: type: string description: >- O status armazenado da verificação: o solicitado, depois que a substituição foi aplicada; o inalterado, enquanto a substituição aguarda a conclusão do fluxo. example: Approved override: $ref: '#/components/schemas/FeatureStatusOverride' required: - session_id - node_id - feature_type - new_status - override examples: Applied: summary: A substituição foi aplicada imediatamente 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 enquanto a pessoa ainda está no fluxo 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: >- Erro de validação. Retornado quando `new_status` é inválido ou não foi alterado, quando `feature_type` é desconhecido ou quando a sessão é uma sessão de API avulsa. content: application/json: examples: Same Status: summary: new_status é igual ao status atual value: new_status: - The new status is the same as the current status. API Session: summary: >- O status do recurso não pode ser alterado em sessões de API avulsas value: - Cannot change feature status for API sessions. Unknown feature_type: summary: feature_type não é um tipo de etapa conhecido value: feature_type: - Unknown feature_type 'SELFIE'. '401': description: A chave de API com escopo expirou. content: application/json: examples: Expired API Key: summary: Chave de API com escopo após a data de validade value: detail: This API key has expired. '403': description: Credenciais ausentes ou permissões insuficientes. content: application/json: examples: Invalid Credentials: summary: x-api-key ausente ou inválido value: detail: >- Authentication credentials were not provided or are invalid. Missing Privilege: summary: A chave de API não tem write:sessions value: detail: You do not have permission to perform this action. Scoped Key Without Access: summary: Chave de API com escopo sem acesso de escrita a decisões value: detail: This API key has no write access to decisions. '404': description: >- A sessão não foi encontrada ou não tem um recurso com o `nodeId` informado. content: application/json: examples: Session Not Found: summary: session_id desconhecido value: detail: Session not found. Feature Not Found: summary: Nenhum recurso para este 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: >- Uma substituição do status de uma verificação (recurso) feita com `PATCH /v3/session/{sessionId}/features/{nodeId}/update-status/`: o que ela altera, se foi aplicada ou ainda aguarda a pessoa concluir o fluxo, quem a solicitou e por quê. 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: >- Identificador da substituição. Passe-o para o endpoint de cancelamento. example: 7c9e6679-7425-40de-944b-e07fc1f90ae7 node_id: type: string description: >- O nó do fluxo indicado na requisição (`default` para uma etapa sem nó). example: feature_ocr_1 feature_type: type: string description: >- O `feature_type` informado na requisição, ou uma string vazia quando nenhum foi informado. example: '' feature_model: type: string description: >- O tipo de verificação que foi sobrescrita, por exemplo `KYC`, `Face`, `AML` ou `GeolocationCheck`. example: KYC previous_status: type: string enum: - Not Finished - Approved - Declined - In Review - Resub Requested description: O status da verificação quando a substituição foi solicitada. example: In Review new_status: type: string enum: - Approved - Declined - In Review description: O status que a substituição define. example: Approved state: type: string enum: - applied - pending_until_flow_finishes - cancelled description: >- `applied`: a verificação está com o novo status. `pending_until_flow_finishes`: a substituição aguarda e é aplicada quando a pessoa conclui o fluxo. `cancelled`: ela aguardou e nunca foi aplicada (veja `cancel_reason`). example: applied forced: type: boolean description: >- `true` quando a substituição foi aplicada imediatamente, enquanto a pessoa ainda estava no fluxo. example: false reason: type: string nullable: true description: O `comment` enviado com a requisição, ou `null`. example: Document manually verified by compliance. requested_by: type: object nullable: true description: >- Quem solicitou a substituição, ou `null` quando isso não é conhecido. properties: email: type: string format: email nullable: true description: >- E-mail do usuário do console, ou `null` para chaves de API e para o sistema. example: reviewer@example.com name: type: string nullable: true description: Nome de exibição do solicitante, ou `null`. example: Alex Reviewer type: type: string enum: - CONSOLE_USER - API_KEY - SYSTEM description: >- Quem fez a requisição: um usuário do console, uma chave de API ou a própria Didit. example: CONSOLE_USER requested_at: type: string format: date-time description: Quando a substituição foi solicitada. example: '2026-10-13T09:15:00Z' applied_at: type: string format: date-time nullable: true description: >- Quando a verificação assumiu o novo status, ou `null` enquanto ela aguarda ou depois de cancelada. example: '2026-10-13T09:15:00Z' cancelled_at: type: string format: date-time nullable: true description: Quando uma substituição pendente foi cancelada, ou `null`. example: null cancel_reason: type: string nullable: true enum: - cancelled_by_reviewer - replaced - check_changed - session_closed - null description: >- Por que uma substituição em espera nunca foi aplicada, ou `null`. `cancelled_by_reviewer`: cancelada com o endpoint de cancelamento. `replaced`: uma substituição mais recente na mesma verificação a substituiu. `check_changed`: a pessoa refez a verificação antes de concluir o fluxo. `session_closed`: a sessão saiu do fluxo antes de a pessoa concluí-lo (abandonada, expirada ou decidida no meio do fluxo). example: null securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: >- Chave de API da sua aplicação, em Developers -> API keys no Business Console. A chave principal tem acesso total. Uma chave nomeada pode ter escopo restrito: nenhum acesso, leitura ou escrita por recurso, limitada a alguns fluxos ou a sessões aprovadas, a uma lista de endereços IP e a uma data de validade. 401 significa que a chave está errada, revogada ou expirada; 403 significa que nenhuma chave foi enviada, que a chave não tem acesso a este recurso ou ação, ou que a requisição veio de um endereço fora da sua lista de IPs; 404 em uma rota de sessão significa que a sessão está fora dos fluxos ou status da chave. Uma chave sem acesso a mídia recebe URLs de imagem, vídeo e PDF como null, e uma chave sem permissão de escrita em sessões recebe links e tokens de sessão como null. Consulte https://docs.didit.me/console/api-keys. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.