Atualizar dados da sessão: corrigir campos KYC e KYB

Às vezes, o OCR lê errado um documento de identidade, uma conta de consumo ou um registro empresarial. A Didit oferece quatro endpoints PATCH que você pode chamar para corrigir os dados extraídos sem precisar refazer toda a verificação.

Endpoint	Quando usar
`PATCH /v3/session/{id}/update-data/`	Corrigir valores extraídos de um documento de identidade em uma sessão de Verificação de Usuário (KYC)
`PATCH /v3/session/{id}/update-poa-data/`	Corrigir valores extraídos de uma conta de consumo, extrato bancário ou contrato de locação em uma sessão de Verificação de Usuário (KYC)
`PATCH /v3/session/{id}/kyb/{company_uuid}/update-data/`	Corrigir campos extraídos do registro de empresas em uma sessão de Verificação de Empresas (KYB)
`PATCH /v3/session/{id}/kyb/parties/{party_uuid}/`	Dispensar da verificação uma pessoa-chave quando ela não puder mais concluir a própria verificação

Os quatro aceitam sua chave de API do cliente ou um cabeçalho de autorização do usuário, e os quatro emitem um webhook data.updated em caso de sucesso, para que seu sistema e suas análises downstream fiquem sincronizados.

Requisitos comuns

Autorização: chave de API do cliente (x-api-key padrão / bearer no Authorization) ou token de autenticação de usuário.
Privilégio:
- KYC e POA: write:sessions
- Empresa KYB e pessoa-chave: write:businesses
Status da sessão (somente KYC / POA): deve ser APPROVED, DECLINED, IN_REVIEW ou KYC_EXPIRED. Sessões que ainda não chegaram a um estado que possa ser revisado não podem ser alteradas. As atualizações de empresa KYB não têm restrição de status.
O registro do recurso precisa existir: você só pode alterar campos de KYC se a sessão tiver uma verificação KYC, campos de POA se tiver uma verificação POA e campos de empresa KYB se a sessão tiver uma consulta ao registro de empresas.
Atualizações parciais: somente os campos que você incluir são alterados. Omita um campo para mantê-lo como está. Envie null para remover uma chave de extra_fields.
Webhooks: uma atualização bem-sucedida dispara data.updated com session_kind: "user" ou "business", e o registro de auditoria da sessão grava quais campos específicos foram alterados e quem os alterou.

Atualizar dados de identidade do KYC

PATCH /v3/session/{sessionId}/update-data/ Altere qualquer campo extraído do documento de identidade. Oferece suporte a fluxos de verificação (workflows) baseados em grafo com múltiplas instâncias por meio de um parâmetro de consulta ou campo do corpo node_id opcional: direcione a requisição a um registro de KYC específico quando uma única sessão tiver várias etapas de KYC.

Campos alteráveis

Campo	Observações
`document_type`	Código ISO do documento: `P` (passaporte), `ID`, `DL`, `RP`.
`document_number`	O número impresso no documento.
`personal_number`	Número pessoal / de identificação fiscal, quando impresso no documento.
`date_of_birth`	Data no formato ISO 8601.
`date_of_issue` / `expiration_date`	Datas no formato ISO 8601.
`issuing_state`	País emissor, ISO 3166-1 alpha-3.
`first_name` / `last_name`	`full_name` é recalculado automaticamente a partir desses dois.
`gender`	`M`, `F` ou `X`, quando presente.
`nationality`	Texto livre.
`marital_status`	Texto livre.
`place_of_birth`	Texto livre.
`address`	Endereço em texto livre extraído do documento. Aciona uma nova geocodificação.
`parsed_address`	Endereço estruturado: veja o formato aninhado abaixo.
`extra_fields`	Campos extras arbitrários do documento de identidade (por exemplo, `blood_group`, `municipality`). Envie `null` como valor de uma chave para removê-la.

parsed_address aceita somente estas chaves aninhadas: address_type, city, region, street_1, street_2, postal_code, country (ISO 3166-1 alpha-2).

Exemplo

curl -X PATCH "https://verification.didit.me/v3/session/4c5c7f3a.../update-data/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "first_name": "John",
    "last_name": "Doe",
    "date_of_birth": "1990-01-01",
    "issuing_state": "ESP",
    "extra_fields": { "municipality": "Madrid" }
  }'

Em um fluxo baseado em grafo com múltiplas instâncias, adicione ?node_id=feature_ocr_2 à URL (ou envie "node_id": "feature_ocr_2" no corpo) para direcionar a requisição a um registro de KYC específico.

Atualizar dados de comprovante de endereço (POA)

PATCH /v3/session/{sessionId}/update-poa-data/ Altere campos extraídos de um documento de comprovante de endereço. As mesmas restrições de status e permissões se aplicam das atualizações de KYC. Também oferece suporte a node_id em fluxos com múltiplas instâncias.

Campos alteráveis

Campo	Observações
`issuing_state`	País que emitiu o documento, ISO 3166-1 alpha-3.
`document_type`	Por exemplo, `utility_bill`, `bank_statement`, `lease_agreement`.
`document_language`	Idioma do documento, ISO 639-1.
`issuer`	Concessionária, banco, locador etc.
`issue_date`	Data no formato ISO 8601.
`poa_address`	Endereço conforme impresso no documento (texto livre). Aciona uma nova geocodificação.
`name_on_document`	Nome completo impresso no documento.
`poa_parsed_address`	Endereço estruturado: mesmo formato aninhado de `parsed_address` do KYC.
`extra_fields`	Campos específicos do documento: dados bancários (`bank_account_number`, `bank_iban`, `bank_sort_code`, `bank_routing_number`, `bank_swift_bic`, `bank_branch_name`, `bank_branch_address`), `document_phone_number`, `additional_names` (lista ou `null`).

Exemplo

curl -X PATCH "https://verification.didit.me/v3/session/4c5c7f3a.../update-poa-data/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "document_type": "utility_bill",
    "issuer": "Iberdrola",
    "issue_date": "2026-03-15",
    "name_on_document": "Jane Doe",
    "poa_parsed_address": {
      "street_1": "Calle Mayor 10",
      "city": "Madrid",
      "postal_code": "28013",
      "country": "ES"
    }
  }'

Atualizar dados da empresa no KYB

PATCH /v3/session/{sessionId}/kyb/{companyUuid}/update-data/ Corrija campos extraídos do registro de empresas de uma empresa no KYB. O endpoint edita tanto as colunas canônicas da empresa quanto registry_data, de modo que a visualização “Extraído do registro de empresas” no console reflita suas correções. user_provided_data (o que o usuário final confirmou no fluxo hospedado) não é modificado. last_console_edit_at é registrado e um webhook data.updated é disparado com trigger: "console_registry_edit".

Requisitos

Privilégio — write:businesses (diferente do privilégio de KYC / POA).
O companyUuid na URL deve pertencer ao sessionId informado; caso contrário, você recebe um 404.
Não há restrição por status da sessão — os dados da empresa no KYB podem ser corrigidos a qualquer momento.

Campos editáveis

Campo	Observações
`company_name`	Razão social.
`registration_number`	Número de registro oficial.
`country_code`	País de constituição, ISO 3166-1 alpha-3.
`incorporation_date` / `registration_date` / `dissolution_date`	Datas em ISO 8601.
`tax_number`	Número de identificação fiscal.
`legal_address`	Alias de `registered_address` — é gravado na coluna canônica `registered_address`.
`company_type`	Ltd / LLC / PLC / SA / GmbH / SL etc.
`registry_status`	`active`, `dissolved`, `struck_off`, `inactive` etc.
`verification_status`	`verified`, `failed`, `unknown`.
`alternative_names`	Nomes comerciais, nomes anteriores, DBAs.
`nature_of_business`	Descrição curta.
`registered_capital`	Capital autorizado / emitido.
`website`, `email`, `phone`	Dados de contato.
`legal_entity_identifier`	LEI.
`location_of_registration`	Cidade / subdivisão.
`control_scheme`	Estrutura de governança, quando o registro de empresas a disponibiliza.

Qualquer campo que você omitir permanece inalterado. Qualquer campo que você enviar é gravado na coluna canônica (quando ela existe) e mesclado em registry_data. As datas são serializadas como strings ISO 8601 ao serem mescladas em registry_data.

Exemplo

curl -X PATCH "https://verification.didit.me/v3/session/bs-01HJX1.../kyb/f7a9c1b2-4e6d.../update-data/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "company_name": "Acme Corporation Limited",
    "registration_number": "12345678",
    "registry_status": "active",
    "legal_address": "1 Main Street, London EC1A 1AA, United Kingdom",
    "alternative_names": "Acme Ltd, Acme Group"
  }'

Resposta: o objeto completo da empresa no KYB — com o mesmo formato de registry_checks[].company na decisão da sessão.

Ignorar uma parte de Pessoas-chave

PATCH /v3/session/{sessionId}/kyb/parties/{partyUuid}/ Isente uma parte de Pessoas-chave da verificação - a saída de emergência para uma parte que nunca conseguirá concluir a própria verificação. A causa mais comum é uma sessão filha excluída: depois que o KYC individual enviado a um UBO ou diretor é excluído, seu status fica congelado e nunca pode ser concluído, então não resta nada no KYB que possa tirá-lo de Awaiting User. Ignorar a parte a remove da agregação de Pessoas-chave, a verificação é recalculada na hora e a sessão pode ser concluída e aprovada ou recusada.

Requisitos

Privilégio - write:businesses.
O partyUuid na URL deve pertencer ao sessionId informado; caso contrário, você recebe um 404.
Não depende de allow_skip. Essa configuração de função limita o que o solicitante pode ignorar ao preencher a tela hospedada de Pessoas-chave; este endpoint permite que o operador substitua essa configuração e funciona mesmo para funções que o solicitante não poderia ignorar.

Corpo

Campo	Tipo	Observações
`is_skipped`	boolean	`true` isenta a parte; `false` a coloca de volta no escopo e a verificação volta a aguardá-la.

requires_verification é deliberadamente mantido inalterado, de modo que uma parte dispensada aparece como requires_verification: true e is_skipped: true - o registro continua mostrando que as regras exigiam uma verificação.

Exemplo

curl -X PATCH "https://verification.didit.me/v3/session/bs-01HJX1.../kyb/parties/0a3f1e2c-7c2f.../" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "is_skipped": true }'

Resposta: a parte atualizada - com o mesmo formato de uma entrada de key_people_checks[].submitted.parties[] na decisão da sessão. Um webhook data.updated é disparado com trigger: "console_key_people_skip".

Uma parte cuja sessão filha foi excluída é sinalizada no payload da decisão com kyc_session_deleted: true (ou kyb_sub_session_deleted: true para partes corporativas), e seu kyc_session_url / kyb_sub_session_url é retornado como null porque o link não funciona mais. Excluir uma sessão filha nunca aprova a parte por si só - a verificação de Pessoas-chave passa para In Review para que uma pessoa tome a decisão.

O que acontece após uma atualização

Webhook — data.updated é disparado na sessão, com o session_kind da sessão no payload ("user" ou "business"). Assine uma única vez no nível do destino e faça o roteamento com base em session_kind.
Trilha de auditoria — a sessão registra exatamente quais campos mudaram, os valores anterior e novo e (em chamadas com autenticação de usuário) o e-mail de quem fez a alteração. Visível na aba Eventos do console.
Nova geocodificação do endereço — em atualizações de KYC e POA que alteram address / poa_address, a Didit executa a geocodificação novamente em segundo plano. Falhas são ignoradas, para que a atualização nunca falhe por causa de um problema de geocodificação.
Nova avaliação de AML — atualizações de KYC que alteram nome / data de nascimento / nacionalidade podem disparar novamente a Análise AML, se o AML ainda não tiver sido concluído na sessão. Os resultados aparecem na decisão da sessão.

Quando não usar estes endpoints

Refazer toda a verificação — se o cliente precisar tirar novamente a foto do documento de identidade ou reenviar um documento, use update-status para mover a sessão para Resubmitted.
Alterar campos de perfil da entidade User ou Business — use PATCH /v3/users/{vendor_data}/ ou PATCH /v3/businesses/{vendor_data}/ — esses endpoints atualizam dados no nível da entidade, não no nível da sessão.
Editar dados de Pessoas-chave - não existe API pública para alterar o nome, as funções ou a propriedade de uma parte; esses dados são enviados pelo fluxo hospedado. O único campo editável é is_skipped (veja Ignorar uma pessoa-chave).

Erros

Status	Significado
`401`	Credenciais ausentes ou inválidas.
`403`	Quem faz a chamada não tem o privilégio necessário (`write:sessions` ou `write:businesses`).
`404`	Sessão não encontrada, ou a sessão não contém o registro que você está alterando (sem KYC, sem POA, sem empresa correspondente, sem parte correspondente ou com uma parte que pertence a outra sessão).
`400`	Erro de validação: código de país inválido, chave de `parsed_address` desconhecida, `extra_fields` que não é um objeto etc.

Próximos passos

Obter sessão

Busque a decisão completa para ver os campos atualizados.

Atualizar status

Aprove, recuse ou reabra uma sessão após corrigir os dados.

Webhooks

Assine os eventos data.updated.

Última modificação em 1 de novembro de 2026

​Requisitos comuns

​Atualizar dados de identidade do KYC

​Campos alteráveis

​Exemplo

​Atualizar dados de comprovante de endereço (POA)

​Campos alteráveis

​Exemplo

​Atualizar dados da empresa no KYB

​Requisitos

​Campos editáveis

​Exemplo

​Ignorar uma parte de Pessoas-chave

​Requisitos

​Corpo

​Exemplo

​O que acontece após uma atualização

​Quando não usar estes endpoints

​Erros

​Próximos passos

Obter sessão

Atualizar status

Webhooks

Requisitos comuns

Atualizar dados de identidade do KYC

Campos alteráveis

Exemplo

Atualizar dados de comprovante de endereço (POA)

Campos alteráveis

Exemplo

Atualizar dados da empresa no KYB

Requisitos

Campos editáveis

Exemplo

Ignorar uma parte de Pessoas-chave

Requisitos

Corpo

Exemplo

O que acontece após uma atualização

Quando não usar estes endpoints

Erros

Próximos passos