> ## 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 Estado da Sessão API: Aprovar e Recusar
> Aprove, recuse ou coloque sessões em análise com PATCH /v3/session/{id}/update-status/ na Didit. KYC e KYB, sem mínimos mensais.
Prompt para atualizar o estado da sessão
Copiar o prompt para a área de transferência
\
\`Manually approve, decline, or re-open a Didit verification session.
Endpoint:
PATCH https://verification.didit.me/v3/session/{session_id}/update-status/
Authentication:
Use the x-api-key header with your Didit API key (or a user-auth token). Privilege: write:sessions.
Path parameter:
\- session_id (UUID) — KYC or KYB; Didit resolves it against both session types.
Request body:
\- new_status (string, required) — One of "Approved", "Declined", "Resubmitted". Any other value is rejected.
\- comment (string, optional) — Free-text note saved on the audit trail (visible in the Console review log).
\- nodes_to_resubmit (array, required when new_status="Resubmitted") — Which feature steps the user must redo. Each entry: { "node_id": "feature_poa_1", "feature": "POA" }. KYB-only nodes "KYB_REGISTRY" and "KYB_KEY_PEOPLE" cannot be resubmitted directly (the parent recomputes from child KYCs).
\- send_email (boolean, optional, default false): if true, email the person. "Approved" and "Declined" send their decision email; "Resubmitted" sends a fresh hosted link with the reasons.
\- email_address (string, required when send_email=true).
\- email_language (string, optional, default "en") — ISO 639-1.
\- email_preview_token (string, optional): the preview_token from Preview Decision Email ("Approved", "Declined") or Preview Resubmission Email ("Resubmitted"). Only valid with send_email=true; without it the request returns 400 { "email_preview_token": ["A preview receipt is only valid when the email is sent."] }. The update then sends exactly the previewed email, or returns 409 before changing anything if the email or the session changed since the preview.
Optional preview step (all three statuses):
1\. Preview the email. Neither call changes the session or sends anything.
\- Approved or Declined: POST https://verification.didit.me/v3/session/{session_id}/decision-email-preview/ with { "new_status": "Approved", "email_language": "en" } (see /sessions-api/preview-decision-email).
\- Resubmitted: POST https://verification.didit.me/v3/session/{session_id}/resubmission-preview/ with { "nodes_to_resubmit": [...], "email_language": "en" } (see /sessions-api/preview-resubmission). email_address is optional there; without it the email goes to the person's own address.
2\. Check subject, html, recipient, will_be_sent and not_sent_reason in the response.
3\. Confirm here with the same new_status (and the same nodes_to_resubmit for Resubmitted), send_email=true, email_address=, email_language=, email_preview_token=.
The receipt expires after 15 minutes.
Allowed transitions:
Current status must be one of: Approved, Declined, In Review, Kyc Expired, Abandoned, Resubmitted. Otherwise the API returns 400 { "detail": "Only sessions with status Approved, Declined, In Review, Kyc Expired, Abandoned, Resubmitted can be updated. Current status: ..." }.
Setting "Approved" or "Declined" on a session that already has that status is a no-op: 200, nothing changes, and no webhook or email goes out. Setting "Resubmitted" on a session that is already Resubmitted returns 400 ["The new status is the same as the current status."].
curl example — approve after manual review:
curl -X PATCH https://verification.didit.me/v3/session//update-status/ \
-H "x-api-key: " \
-H "Content-Type: application/json" \
-d '{
"new_status": "Approved",
"comment": "Cleared after compliance review."
}'
curl example: approve and send the email you previewed:
curl -X PATCH https://verification.didit.me/v3/session//update-status/ \
-H "x-api-key: " \
-H "Content-Type: application/json" \
-d '{
"new_status": "Approved",
"send_email": true,
"email_address": "",
"email_language": "en",
"email_preview_token": ""
}'
curl example — request resubmission of the proof-of-address step:
curl -X PATCH https://verification.didit.me/v3/session//update-status/ \
-H "x-api-key: " \
-H "Content-Type: application/json" \
-d '{
"new_status": "Resubmitted",
"nodes_to_resubmit": [{ "node_id": "feature_poa_1", "feature": "POA" }],
"comment": "Please upload a clearer proof of address",
"send_email": true,
"email_address": "user@example.com"
}'
Response: { "session_id": "" } only. Fetch the refreshed session with GET /v3/session/{session_id}/decision/.
Side effects:
\- Fires a status.updated webhook (plus user.status.updated or business.status.updated alias).
\- Writes an entry to the Console review trail with the actor and your comment.
\- "Approved" or "Declined" with send_email=true emails the decision to email_address. Preview Decision Email tells you beforehand whether it will be sent (for example, not to the contact_details address of a session created without contact_details.send_notification_emails=true).
\- "Resubmitted" sends the user back to the steps in nodes_to_resubmit, resets the session expiration window, and (if send_email=true) emails the user a fresh link. What those steps returned before stays readable: the decision endpoint returns it with include=resubmissions (see Retrieve Session).
Failure modes:
\- 400: invalid new_status (only "Approved", "Declined" and "Resubmitted" are accepted), current status not allowed, nothing to resubmit, send_email=true without email_address, or email_preview_token without send_email=true. Field errors look like { "": ["..."] }.
\- 401: the scoped API key has expired.
\- 403: { "detail": "..." } when credentials are missing or invalid, the caller lacks write:sessions (a scoped API key needs decisions write), or the session belongs to another application.
\- 404: { "detail": "Not found." } when no session with this session_id exists.
\- 409: { "detail": "This email preview changed or expired. Preview the message again before confirming." } when email_preview_token no longer matches the email or the session, or is older than 15 minutes. Nothing changed and no email was sent: preview again.
\- 429 - { "detail": "..." } when a resubmit that only targets backend-only features (AML, DATABASE_VALIDATION, IP_ANALYSIS) repeats within 30 seconds of the previous resubmit. Those features re-run automatically with no user interaction, so an immediate repeat cannot change the outcome; honor the Retry-After header instead of retrying in a loop (e.g. from a webhook handler).
Idempotency:
Repeating "Approved" or "Declined" returns 200 and changes nothing. Repeating "Resubmitted" returns 400.
Next step:
After updating, call GET /v3/session/{session_id}/decision/ to fetch the refreshed payload — see /sessions-api/retrieve-session.
For end-to-end Didit integration, paste in the full prompt at /integration/integration-prompt.`
\
Colar em
## Suporte a KYC e KYBEste endpoint funciona de forma idêntica para sessões de **Verificação de utilizadores (KYC)** e de **Verificação de empresas (KYB)**. A Didit resolve o `session_id` nos dois tipos de sessão, e a validação das transições de estado é a mesma para ambos (o mesmo enum de estados se aplica a ambos).A resposta inclui apenas o `session_id`.
Leia o `session_kind` a partir de [Obter sessão](https://docs.didit.me/pt/sessions-api/retrieve-session.md) quando a sua lógica a jusante precisar de distinguir o tipo.## Transições permitidasPode mover uma sessão para `Approved`, `Declined` ou `Resubmitted`.
Qualquer outro `new_status`, incluindo `In Review`, devolve `400`.
O estado atual da sessão tem de ser `Approved`, `Declined`, `In Review`, `Kyc Expired`, `Abandoned` ou `Resubmitted`; caso contrário, a API devolve `400`.Definir `Approved` ou `Declined` numa sessão que já tem esse estado é uma operação sem efeito: a API devolve `200`, não altera nada, não dispara nenhum webhook e não envia nenhum e-mail.
Definir `Resubmitted` numa sessão que já está `Resubmitted` devolve `400` (`The new status is the same as the current status.`).Um reenvio cujos `nodes_to_resubmit` contenham apenas funcionalidades exclusivas do backend (`AML`, `DATABASE_VALIDATION`, `IP_ANALYSIS`) é executado automaticamente e devolve a sessão a um estado com decisão tomada, sem qualquer interação do utilizador.
Repetir um reenvio desse tipo nos 30 segundos seguintes devolve `429 Too Many Requests` com um cabeçalho `Retry-After`, uma vez que uma repetição imediata não pode produzir um resultado diferente.
Não reenvie automaticamente a partir de um processador de webhook sempre que receber o estado `In Review`: primeiro analise o resultado ou altere os dados subjacentes.## Pré-visualizar o e-mail primeiroCom `send_email: true`, `Approved` e `Declined` enviam à pessoa o e-mail de decisão, e `Resubmitted` envia-lhe uma nova ligação com os motivos.
Pode ver esse e-mail antes de alterar qualquer coisa:1) Chame [Pré-visualizar e-mail de decisão](https://docs.didit.me/pt/sessions-api/preview-decision-email.md) para `Approved` ou `Declined`, ou [Pré-visualizar e-mail de reenvio](https://docs.didit.me/pt/sessions-api/preview-resubmission.md) para `Resubmitted`.
2) Verifique o `subject` e o `html` renderizados, o `recipient` e o `will_be_sent` / `not_sent_reason`.
3) Chame este endpoint com o mesmo `new_status` (e, no caso de um reenvio, os mesmos `nodes_to_resubmit`), `send_email: true`, `email_address` definido como `recipient`, o `email_language` que pré-visualizou e `email_preview_token` definido como `preview_token`.Nenhuma das pré-visualizações altera a sessão nem envia qualquer coisa.
A atualização envia então exatamente o e-mail que pré-visualizou.
O recibo expira após 15 minutos.
Se o destinatário, o idioma, o estado da sessão, o remetente ou o e-mail tiverem mudado desde a pré-visualização, a atualização devolve `409` antes de alterar seja o que for; pré-visualize de novo e confirme com o novo recibo.
Enviar `email_preview_token` sem `send_email: true` devolve `400`.
O passo de pré-visualização é opcional: as integrações existentes podem continuar a chamar este endpoint sem ele.## Exemplos> [tab] Aprovar uma sessão de Verificação de utilizadores (KYC)
>
> ```bash theme={null}
> curl -X PATCH https://verification.didit.me/v3/session/4c5c7f3a-.../update-status/ \
> -H "x-api-key: YOUR_API_KEY" \
> -H "Content-Type: application/json" \
> -d '{
> "new_status": "Approved",
> "comment": "Cleared after manual review by compliance team"
> }'
> ```> [tab] Recusar uma sessão de Verificação de empresas (KYB)
>
> ```bash theme={null}
> curl -X PATCH https://verification.didit.me/v3/session/bs-01HJX1.../update-status/ \
> -H "x-api-key: YOUR_API_KEY" \
> -H "Content-Type: application/json" \
> -d '{
> "new_status": "Declined",
> "comment": "Sanctioned subsidiary detected in ownership chain"
> }'
> ```> [tab] Pedir um reenvio
>
> ```bash theme={null}
> curl -X PATCH https://verification.didit.me/v3/session/.../update-status/ \
> -H "x-api-key: YOUR_API_KEY" \
> -H "Content-Type: application/json" \
> -d '{
> "new_status": "Resubmitted",
> "nodes_to_resubmit": [
> { "node_id": "feature_poa_1", "feature": "POA" }
> ],
> "comment": "Please upload a clearer proof of address",
> "send_email": true,
> "email_address": "user@example.com"
> }'
> ```> [tab] Aprovar e enviar o e-mail pré-visualizado
>
> ```bash theme={null}
> curl -X PATCH https://verification.didit.me/v3/session/.../update-status/ \
> -H "x-api-key: YOUR_API_KEY" \
> -H "Content-Type: application/json" \
> -d '{
> "new_status": "Approved",
> "send_email": true,
> "email_address": "user@example.com",
> "email_language": "en",
> "email_preview_token": "PREVIEW_TOKEN_FROM_THE_PREVIEW"
> }'
> ```## PermissãoRequer o privilégio `write:sessions`. O mesmo privilégio abrange os dois tipos.## Relacionados- [Estados de verificação](https://docs.didit.me/pt/integration/verification-statuses.md): referência da máquina de estados.
- [Obter sessão](https://docs.didit.me/pt/sessions-api/retrieve-session.md): obtenha a decisão depois de atualizar.
- [Visão geral das sessões](https://docs.didit.me/pt/sessions-api/overview.md): distinção entre tipos.
- [Pré-visualizar e-mail de decisão](https://docs.didit.me/pt/sessions-api/preview-decision-email.md): veja o e-mail de Approved ou Declined antes de o enviar.
- [Pré-visualizar e-mail de reenvio](https://docs.didit.me/pt/sessions-api/preview-resubmission.md): veja o e-mail de reenvio antes de o enviar.
## OpenAPI
````yaml pt/openapi-25.json PATCH /v3/session/{sessionId}/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}/update-status/:
patch:
tags:
- Sessions
summary: Aprovar, recusar ou solicitar novo envio para uma sessão de verificação
description: >-
Substitua manualmente a decisão final de uma sessão de verificação KYC
ou KYB. Defina `new_status` como `Approved` ou `Declined` para registar
uma decisão manual, ou como `Resubmitted` para limpar passos de
verificação específicos e permitir que o utilizador os repita através do
mesmo URL de verificação. O endpoint aceita tanto IDs de sessão de
utilizador (KYC) como de empresa (KYB).
Chame-o quando uma sessão tiver atingido um estado passível de revisão:
o estado atual deve ser `Approved`, `Declined`, `In Review`, `Kyc
Expired`, `Abandoned` ou `Resubmitted`. As sessões que ainda estejam em
`Not Started`, `In Progress` ou `Awaiting User`, ou que tenham terminado
como `Expired`, devolvem `400`. A sua chave de API necessita da
permissão `write:sessions` (uma chave de API com âmbito necessita de
acesso de escrita a decisões). A verificação de estado elegível é
executada antes da validação do corpo, pelo que uma sessão inelegível
devolve o erro `Wrong Current Status`, mesmo quando o payload também é
inválido.
Para `Resubmitted`, passe `nodes_to_resubmit` para escolher quais os
passos do fluxo que o utilizador deve repetir, ou omita-o para
selecionar automaticamente tentativas de funcionalidades existentes num
estado ressubmissível (`Declined`, `In Review`, `Not Finished`,
`Expired`). As funcionalidades nunca tentadas não são selecionadas
automaticamente: liste-as explicitamente em `nodes_to_resubmit`, caso
contrário o pedido devolve `400` quando nenhuma tentativa registada
necessitar de ressubmissão. Os resultados anteriores dos passos
selecionados passam para o histórico da ressubmissão (devolvido por Get
Decision com `include=resubmissions`), os passos são reordenados para
corresponder ao grafo do fluxo, a janela de expiração da sessão é
reiniciada e o URL de verificação original volta a ficar utilizável. Os
passos exclusivos de backend (`AML`, `DATABASE_VALIDATION`,
`IP_ANALYSIS`) no início da lista são executados imediatamente sem
interação do utilizador; se todos os passos ressubmetidos forem
exclusivos de backend, a sessão volta a ser finalizada no âmbito do
mesmo pedido. `KYB_REGISTRY` e `KYB_KEY_PEOPLE` não podem ser
ressubmetidos diretamente: em alternativa, ressubmeta as sessões KYC
subordinadas relevantes e a sessão da empresa principal será recalculada
automaticamente.
Cada chamada que altere o estado dispara o
[webhook](/pt/integration/webhooks) `status.updated` assim que a
alteração for confirmada e adiciona uma entrada de atividade (com
atribuição do autor e o seu `comment`) às `reviews` da sessão, visível
em [Get Decision](#get-/v3/session/-sessionId-/decision/) e na
cronologia de atividade da consola. Os agregados do perfil de utilizador
associados a `vendor_data` da sessão também são atualizados. A recusa
desativa a monitorização AML contínua para a sessão; a reaprovação
reativa-a (a partir de `Resubmitted`, `Declined` ou `Kyc Expired`) se o
fluxo tiver a monitorização ativada. A aprovação ou recusa de um KYC
subordinado pertencente a uma verificação de pessoas-chave de KYB
recalcula o estado da sessão da empresa principal. Defina `send_email:
true` (com `email_address`) para notificar o utilizador: um aviso de
estado para `Approved`/`Declined`, ou um e-mail de ressubmissão contendo
a ligação de verificação e os motivos por passo para `Resubmitted`. Para
verificar o e-mail primeiro, pré-visualize-o com [Preview Decision
Email](/pt/sessions-api/preview-decision-email) (`Approved`, `Declined`)
ou [Preview Resubmission Email](/pt/sessions-api/preview-resubmission)
(`Resubmitted`) e passe o respetivo `preview_token` como
`email_preview_token`: a atualização envia então exatamente o e-mail
pré-visualizado, ou devolve `409` antes de alterar qualquer elemento se
o e-mail ou a sessão tiverem mudado desde a pré-visualização ou se o
recibo tiver mais de 15 minutos.
Repetir `Approved` ou `Declined` numa sessão que já tenha esse estado
não altera nada e devolve `200`: nenhum webhook, nenhuma entrada de
atividade e nenhum e-mail. Repetir `Resubmitted` devolve `400` (`The new
status is the same as the current status.`). Credenciais em falta ou
inválidas e permissões em falta devolvem `403`; uma chave de API com
âmbito expirada devolve `401`.
operationId: patch_v3_session_update_status
parameters:
- in: path
name: sessionId
required: true
description: >-
UUID da sessão de verificação a atualizar. Aceita IDs de sessão de
utilizador (KYC) e de empresa (KYB) — o serviço resolve o ID em
ambos os tipos de sessão.
schema:
type: string
format: uuid
example: 11111111-2222-3333-4444-555555555555
requestBody:
required: true
content:
application/json:
schema:
type: object
required:
- new_status
properties:
new_status:
type: string
description: >-
Estado de destino. `Approved` e `Declined` registam uma
decisão manual final (cada uma também pode revogar a outra).
`Resubmitted` limpa os passos selecionados e envia a sessão
de volta ao utilizador. Qualquer outro valor devolve `400`.
enum:
- Approved
- Declined
- Resubmitted
example: Approved
comment:
type: string
description: >-
Motivo em texto livre para a alteração, guardado no
histórico de revisão da sessão e devolvido no array
`reviews` de [Get
Decision](#get-/v3/session/-sessionId-/decision/). Por
exemplo, `Duplicated user`.
example: All checks passed manual review
nodes_to_resubmit:
type: array
description: >-
Passos do fluxo que o utilizador deve repetir. Apenas
considerados quando `new_status` é `Resubmitted`. Para
`Approved`/`Declined`, as entradas continuam a ser validadas
pelo schema (um valor inválido de `feature` devolve `400`),
mas as entradas válidas no schema são semanticamente
ignoradas. Se for omitido, o servidor seleciona
automaticamente tentativas existentes de OCR, Prova de vida,
Correspondência facial, Comprovativo de morada, Telefone,
E-mail, AML, Validação de base de dados e Questionário cujo
estado seja `Declined`, `In Review`, `Not Finished` ou
`Expired` (tentativas de NFC, análise de IP, estimativa de
idade, pesquisa facial e documentos KYB nunca são
selecionadas automaticamente; tentativas faciais que não
sejam de correspondência facial são selecionadas como
`LIVENESS`) — funcionalidades que o utilizador nunca tentou
(sem tentativa registada) NÃO são selecionadas, pelo que uma
sessão com zero tentativas devolve `400` ("No features found
that need resubmission"), mesmo que nada tenha sido
aprovado; passe `nodes_to_resubmit` explicitamente nesse
caso. Os passos são executados na ordem do grafo do fluxo,
independentemente da ordem em que os envia. `KYB_REGISTRY`,
`KYB_KEY_PEOPLE` e o alias `KYB` são rejeitados com `400` —
essas verificações principais são recalculadas a partir das
respetivas sessões KYC filhas.
items:
type: object
required:
- node_id
- feature
properties:
node_id:
type: string
description: >-
Identificador do nó tal como aparece na definição do
fluxo da sessão (por exemplo `feature_ocr`,
`feature_liveness`).
example: feature_ocr
feature:
type: string
description: >-
Tipo de funcionalidade do nó. Os aliases
`ID_VERIFICATION`, `POA`, `PHONE` e `EMAIL` são
normalizados do lado do servidor para `OCR`,
`PROOF_OF_ADDRESS`, `PHONE_VERIFICATION` e
`EMAIL_VERIFICATION`. `KYB_REGISTRY`, `KYB_KEY_PEOPLE`
e `KYB` passam na validação do esquema, mas são sempre
rejeitados com a regra de negócio `400` mostrada nos
exemplos.
enum:
- OCR
- OCR_BACK
- NFC
- AML
- FACE
- LIVENESS
- FACE_MATCH
- IP_ANALYSIS
- AGE_ESTIMATION
- PROOF_OF_ADDRESS
- PHONE_VERIFICATION
- EMAIL_VERIFICATION
- FACE_SEARCH
- DATABASE_VALIDATION
- QUESTIONNAIRE
- DOCUMENT_AI
- KYB_DOCUMENTS
- ID_VERIFICATION
- POA
- PHONE
- EMAIL
- KYB_REGISTRY
- KYB_KEY_PEOPLE
- KYB
- GEOLOCATION
example: OCR
send_email:
type: boolean
description: >-
Se deve ser enviado um e-mail ao utilizador sobre a
alteração. Requer `email_address`. Para
`Approved`/`Declined`, o utilizador recebe um aviso de
estado; para `Resubmitted`, o e-mail inclui a ligação de
verificação e os motivos de reenvio por passo.
default: false
example: false
email_address:
type: string
format: email
description: >-
Destinatário do e-mail de notificação. **Obrigatório quando
`send_email` for `true`** — omiti-lo devolve `400`.
example: user@example.com
email_language:
type: string
description: >-
Idioma do e-mail de notificação. Aceita qualquer cadeia de
caracteres ao nível do esquema; códigos não suportados
revertem silenciosamente para inglês (`en`).
default: en
example: en
email_preview_token:
type: string
writeOnly: true
minLength: 1
maxLength: 512
description: >-
Recibo opcional de [Pré-visualizar e-mail de
decisão](/pt/sessions-api/preview-decision-email) (para
`Approved` e `Declined`) ou [Pré-visualizar e-mail de nova
submissão](/pt/sessions-api/preview-resubmission) (para
`Resubmitted`): o respetivo `preview_token`. Válido apenas
com `send_email: true`; sem este, o pedido devolve `400`. O
destinatário, idioma, estado da sessão, remetente e e-mail
(e, para uma nova submissão, os passos selecionados) têm de
continuar a coincidir com a pré-visualização, e o recibo
expira após 15 minutos. Caso contrário, o pedido devolve
`409` antes de a sessão ser alterada ou de ser enviado um
e-mail. As integrações existentes podem omitir este campo.
examples:
Approve Session:
summary: Aprovar uma sessão após revisão manual
value:
new_status: Approved
comment: All checks passed manual review
Decline Session:
summary: Recusar uma sessão
value:
new_status: Declined
comment: Suspected fraud
Resubmit Specific Steps:
summary: Pedir reenvio dos passos selecionados, com e-mail
value:
new_status: Resubmitted
nodes_to_resubmit:
- node_id: feature_ocr
feature: OCR
- node_id: feature_liveness
feature: LIVENESS
send_email: true
email_address: user@example.com
email_language: en
Resubmit Auto-select:
summary: >-
Pedir reenvio (selecionar automaticamente os passos não
aprovados)
value:
new_status: Resubmitted
Approve With Previewed Email:
summary: >-
Aprovar e enviar o e-mail devolvido por Pré-visualizar e-mail
de decisão
value:
new_status: Approved
send_email: true
email_address: person@example.com
email_language: en
email_preview_token: >-
eyJkaWdlc3QiOiI0ZjJhIn0:1uExAm:Pl3x4mpleS1gnatureValue000000000000000
responses:
'200':
description: >-
Estado atualizado. A resposta contém apenas o `session_id`; obtenha
a sessão atualizada através de [Get
Decision](#get-/v3/session/-sessionId-/decision/). O webhook
`status.updated` é disparado assim que a alteração for confirmada.
Repetir `Approved` ou `Declined` devolve o mesmo corpo e não altera
nada.
content:
application/json:
schema:
type: object
properties:
session_id:
type: string
format: uuid
description: UUID da sessão atualizada.
examples:
Updated:
summary: Devolvido da mesma forma para Aprovada, Recusada e Reenviada
value:
session_id: 3472fb7c-8f7c-4d1a-9cf4-cf3d74ce1a60
'400':
description: >-
Erro de validação. Os erros de campo chegam como `{"":
[""]}` (algumas recusas de regras de negócio utilizam um
valor de string: `{"nodes_to_resubmit": ""}`), erros entre
estados como `{"detail": ""}` e o erro de mesmo estado como
um array JSON simples.
content:
application/json:
examples:
Wrong Current Status:
summary: A sessão não está num estado atualizável
value:
detail: >-
Only sessions with status Approved, Declined, In Review,
Kyc Expired, Abandoned, Resubmitted can be updated.
Current status: In Progress
Invalid Status Value:
summary: >-
new_status é um estado de sessão real, mas não é um de
Approved/Declined/Resubmitted
value:
new_status:
- >-
You can only update the status to 'Approved',
'Declined', or 'Resubmitted'.
Missing new_status:
summary: Campo obrigatório omitido
value:
new_status:
- This field is required.
Same Status:
summary: Reenvio solicitado numa sessão que já se encontra reenviada
value:
- The new status is the same as the current status.
Email Address Required:
summary: send_email true sem email_address
value:
email_address:
- Email address is required when send_email is true.
Non-resubmittable Feature:
summary: O reenvio tem como alvo uma verificação-pai de KYB
value:
nodes_to_resubmit: >-
The following features cannot be resubmitted directly:
KYB_REGISTRY. Resubmit the relevant child KYC sessions
instead; the parent will recompute automatically.
Nothing To Resubmit:
summary: >-
A seleção automática não encontrou funcionalidades não
aprovadas
value:
nodes_to_resubmit: >-
No features found that need resubmission. All features are
already approved.
Invalid Feature Choice:
summary: Funcionalidade desconhecida em nodes_to_resubmit
value:
nodes_to_resubmit:
- feature:
- >-
"BOGUS" is not a valid choice. Valid choices are:
OCR, OCR_BACK, NFC, AML, FACE, LIVENESS, FACE_MATCH,
IP_ANALYSIS, AGE_ESTIMATION, PROOF_OF_ADDRESS,
PHONE_VERIFICATION, EMAIL_VERIFICATION, FACE_SEARCH,
DATABASE_VALIDATION, QUESTIONNAIRE, KYB_REGISTRY,
KYB_DOCUMENTS, KYB_KEY_PEOPLE, ID_VERIFICATION, POA,
PHONE, EMAIL, KYB
Invalid Status Value (not a status at all):
summary: new_status não é um valor de StatusChoices válido
value:
new_status:
- '"Bogus" is not a valid choice.'
Preview Receipt Without Email:
summary: 'email_preview_token enviado sem send_email: true'
value:
email_preview_token:
- A preview receipt is only valid when the email is sent.
'401':
description: A chave de API com âmbito expirou.
content:
application/json:
examples:
Expired API Key:
summary: Chave de API com âmbito cuja data de validade já passou
value:
detail: This API key has expired.
'403':
description: >-
Credenciais em falta ou permissões insuficientes, ou um `session_id`
que pertence a outra aplicação.
content:
application/json:
examples:
Invalid Credentials:
summary: x-api-key em falta 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.
'404':
description: >-
Não existe nenhuma sessão de KYC ou KYB com este `session_id`
(sessões eliminadas também devolvem `404`).
content:
application/json:
examples:
Not Found:
summary: session_id desconhecido
value:
detail: Not found.
'409':
description: >-
A pré-visualização do e-mail foi alterada ou expirou. Gere uma nova
pré-visualização antes de confirmar; não ocorre nenhuma alteração de
sessão nem entrega de e-mail.
content:
application/json:
examples:
Preview Changed:
summary: O recibo já não corresponde ou tem mais de 15 minutos
value:
detail: >-
This email preview changed or expired. Preview the message
again before confirming.
'429':
description: >-
Um reenvio focado apenas em funcionalidades de backend (AML,
DATABASE_VALIDATION, IP_ANALYSIS) foi repetido dentro do intervalo
de espera de 30 segundos; uma repetição imediata não altera o
resultado. Aguarde e tente novamente após o intervalo indicado em
`Retry-After`.
content:
application/json:
examples:
Backend-only resubmit throttled:
value:
detail: >-
This session was already resubmitted for backend-only
features within the last 30 seconds; repeating it cannot
change the outcome. Wait before resubmitting again.
security:
- ApiKeyAuth: []
x-codeSamples:
- lang: curl
label: curl
source: |-
curl -X PATCH \
https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/update-status/ \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{
"new_status": "Approved",
"comment": "All checks passed manual review"
}'
- lang: python
label: Python
source: |-
from didit import Didit
# Reads DIDIT_API_KEY.
client = Didit()
result = client.sessions.update_status(
"11111111-2222-3333-4444-555555555555",
new_status="Approved",
comment="All checks passed manual review",
)
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.updateStatus("11111111-2222-3333-4444-555555555555",
{
new_status: "Approved",
comment: "All checks passed manual review",
});
console.log(result);
- lang: go
label: Go
source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Sessions.UpdateStatus(ctx, \"11111111-2222-3333-4444-555555555555\", didit.SessionsUpdateStatusParams{\n\tNewStatus: \"Approved\",\n\tComment: didit.String(\"All checks passed manual review\"),\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.SessionsUpdateStatusParams;
// Reads DIDIT_API_KEY.
Didit client = new Didit();
var result =
client.sessions().updateStatus("11111111-2222-3333-4444-555555555555",
SessionsUpdateStatusParams.builder()
.newStatus(SessionsUpdateStatusParams.NewStatus.of("Approved"))
.comment("All checks passed manual review")
.build());
System.out.println(result);
- lang: php
label: PHP
source: >-
sessions->updateStatus('11111111-2222-3333-4444-555555555555',
[
'new_status' => 'Approved',
'comment' => 'All checks passed manual review',
]);
print_r($result->toArray());
- lang: ruby
label: Ruby
source: |-
require "didit"
# Reads DIDIT_API_KEY.
didit = Didit::Client.new
result = didit.sessions.update_status(
"11111111-2222-3333-4444-555555555555",
new_status: "Approved",
comment: "All checks passed manual review"
)
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.UpdateStatusAsync("11111111-2222-3333-4444-555555555555",
new SessionsUpdateStatusParams
{
NewStatus = "Approved",
Comment = "All checks passed manual review",
});
Console.WriteLine(JsonSerializer.Serialize(result));
components:
securitySchemes:
ApiKeyAuth:
type: apiKey
in: header
name: x-api-key
description: >-
A chave de API da sua aplicação, a partir de Programadores -> Chaves de
API na Business Console. A chave principal tem acesso total. Uma chave
nomeada pode ter o âmbito definido: nenhum, 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á
incorreta, 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 o
pedido veio de um endereço fora da sua lista de IP; 404 numa rota de
sessão significa que a sessão está fora dos fluxos ou estados da chave.
Uma chave sem acesso a multimédia recebe URLs de imagens, vídeos e PDFs
como nulos, e uma chave sem permissão de escrita em sessões recebe
ligações de sessão e tokens como nulos. Consulte
https://docs.didit.me/console/api-keys.
````
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.