Pular para o conteúdo principal
DELETE

Suporte a KYC e KYB

Funciona tanto para sessões de Verificação de Usuário (KYC) quanto de Verificação de Empresas (KYB). O session_id é buscado nos dois tipos de sessão, e o mesmo comportamento de exclusão se aplica a ambos. A retenção do template biométrico se aplica apenas a sessões KYC, porque somente sessões KYC contêm um embedding facial.

Comportamento

  • A sessão é excluída junto com todas as tentativas de verificação que ela contém, incluindo resultados substituídos por um reenvio: sua decisão, seus dados extraídos, os registros dos recursos associados (verificações de identidade, consultas a registros, documentos, AML, análise de IP etc.), suas revisões e seu registro de atividades, além de todos os arquivos armazenados.
  • Excluir uma sessão de Verificação de Empresas (KYB) também exclui, de forma recursiva, as verificações que ela criou para suas pessoas-chave (KYC) e para seus proprietários corporativos (KYB). A resposta informa quantas foram excluídas em deleted_child_verifications. Uma verificação à qual ela apenas faz referência, como um KYC aprovado já existente que foi reutilizado, não é excluída.
  • Os dados de assinatura eletrônica também são excluídos: os documentos a assinar e seus arquivos Word originais, os PDFs assinados, os PDFs de evidências, as imagens das assinaturas e o valor de cada campo. Os caminhos de download desses arquivos retornam 404.
  • A sessão desaparece imediatamente das respostas de listagem e de decisão, e as URLs de mídia emitidas antes da chamada deixam de funcionar.
  • As entregas de webhook ainda na fila para a sessão, assim como suas novas tentativas, são descartadas.
  • O monitoramento AML contínuo e o monitoramento de registros KYB iniciados pelas verificações excluídas são interrompidos.
  • A exclusão é permanente e irreversível. Não existe endpoint de restauração, então exporte tudo de que você precisar, como o PDF de uma decisão, antes de fazer a chamada.
  • A resposta é 200 OK, enviada quando a exclusão é concluída, com um corpo JSON que informa o que aconteceu com os dados biométricos faciais da sessão. Consulte Migração se o seu cliente ainda espera 204.

Dados em um relatório regulatório finalizado

Se a sessão fizer parte de um caso com um relatório regulatório finalizado, a requisição retorna 409 e nada é excluído. A resposta usa code: in_filed_report e identifica cada relatório:
Exclua cada relatório com Excluir relatório e, em seguida, repita a exclusão. Excluir o relatório não exclui a sessão: ela permanece até que você chame este endpoint novamente.

Dados biométricos faciais: excluir ou reter

Toda sessão de KYC com uma selfie de prova de vida contém um embedding facial que alimenta a Busca facial 1:N e a detecção de duplicatas. Por padrão, esse embedding é excluído junto com a sessão (face_retention_policy: delete_with_session), para que uma pessoa cuja sessão você excluiu possa se verificar novamente sem ser sinalizada como duplicata. Aplicações que precisam que a detecção de duplicatas continue funcionando após a exclusão da sessão podem optar pela retenção de template biométrico. Nesse caso, a Didit exclui a sessão e todos os seus dados normalmente, e mantém um template biométrico facial sem imagem, gerenciado separadamente e vinculado ao Usuário da sessão.
Um template biométrico retido é um dado biométrico. Ele não é anônimo, não é temporário e não é excluído junto com a sessão. Ele permanece até a expiração programada, até um prazo anterior exigido pela legislação aplicável, até a exclusão do Usuário, até uma solicitação de apagamento por privacidade ou até uma eliminação explícita. Ative a retenção somente quando a instrução do controlador e o seu aviso de privacidade a cobrirem.
O que um template retido contém e o que não contém: A retenção é configurada em três lugares, do mais amplo ao mais específico:
  1. Política da aplicação em Business Console → App Settings → Data retention ou por meio de PATCH /v3/webhook/ (face_retention_policy, face_retention_days). Consulte Retenção de dados.
  2. Substituição por requisição com retain_face_embeddings neste endpoint e em Excluir sessões em lote.
  3. Classe de instrução com deletion_instruction. Uma instrução privacy_erasure sempre prevalece: ela remove todos os templates retidos desse Usuário e nunca retém um novo.

Corpo da requisição

Todos os campos são opcionais. Omita o corpo para seguir a política da aplicação.

Resposta

A resposta confirma que a Didit aceitou e aplicou a sua instrução de exclusão. Ela não é um certificado de apagamento: guarde o instruction_id no seu próprio registro de apagamentos para poder correlacioná-lo com a trilha de auditoria depois.

Duração e expiração da retenção

Todo template retido tem um expires_at finito. A Didit o define como a data mais próxima entre:
  1. o face_retention_days da requisição, ou o face_retention_days da aplicação quando a requisição o omite;
  2. a janela geral de retenção de dados da aplicação, quando houver uma configurada;
  3. o face_retention_deadline da requisição, quando informado.
Uma requisição que reteria um template sem nenhuma duração finita é rejeitada com 400 e nada é excluído. Os templates retidos não podem ultrapassar o primeiro dos seguintes marcos: instrução aplicável do cliente, fim da finalidade, expiração configurada, instrução de apagamento do titular dos dados ou prazo legal para dados biométricos. Você é responsável por escolher uma duração que atenda às leis aplicáveis aos seus usuários; escolha uma mais curta sempre que uma regra aplicável exigir.

Apagamento por privacidade

Envie deletion_instruction: "privacy_erasure" quando estiver atendendo a uma solicitação de um titular de dados. A Didit elimina todos os templates biométricos retidos vinculados ao Usuário da sessão e, em seguida, exclui a sessão e o seu embedding. A política de retenção da aplicação não pode se sobrepor a uma instrução de apagamento por privacidade, e retain_face_embeddings: true é rejeitado com 400. Excluir o Usuário com Excluir usuários em lote também elimina os templates retidos dele.

O que não é afetado

Excluir uma sessão não remove os itens abaixo por você. Se você estiver atendendo a uma solicitação de exercício do direito ao apagamento, trate-os separadamente.
  • As entradas da lista de bloqueio criadas a partir da sessão (de rosto ou de documento) permanecem. Remova-as da lista de bloqueio. Uma entrada de rosto na lista de bloqueio mantém o seu próprio registro biométrico, independente de qualquer template retido.
  • Os tokens de compartilhamento já emitidos para a sessão não são revogados, mas não resta nada para eles importarem: uma importação com um deles retorna 400 com {"share_token": ["Original session does not exist."]}.
  • Os webhooks já entregues para a sessão não são afetados. As entregas ainda na fila e suas tentativas de reenvio são descartadas. Nenhum webhook é emitido para a exclusão em si.
  • Os créditos já consumidos pela verificação não são reembolsados.
  • As cópias assinadas já enviadas por e-mail a um signatário por uma etapa de Assinatura eletrônica estão na caixa de correio do signatário e não são afetadas.
  • A entidade Usuário ou Empresa à qual a sessão pertence não é excluída. Use Excluir usuários ou Excluir empresas para isso. Se o retrato do perfil do Usuário veio da sessão excluída, o retrato é removido.
  • Um template biométrico retido (somente quando você optou por isso) permanece até expirar ou até você eliminá-lo. Elimine-o com a API de templates biométricos, excluindo o Usuário ou repetindo a exclusão de outra sessão do mesmo Usuário com deletion_instruction: "privacy_erasure".

Exemplos

Resposta para uma aplicação que não optou pela retenção:

Erros

Com 400, nada é excluído. Com 503, a sessão ainda existe: repita a mesma requisição até ela retornar 200. Alguns dos arquivos armazenados da sessão ou o embedding facial dela podem já ter sido excluídos, então não dependa deles após um 503.

Permissão

Requer delete:sessions. A mesma permissão abrange as sessões de Verificação de Usuários (KYC) e de Verificação de Empresas (KYB), além da substituição da retenção.

Exclusão em lote

Para operações em massa em sessões de KYC, use POST /v3/sessions/delete/. Ele aceita os mesmos campos de retenção e de instrução. Até 20 sessões correspondentes são excluídas na própria requisição, com um resultado por sessão; acima disso, a exclusão é executada como um job de exclusão. Consulte Excluir sessões em lote.

Migração das respostas 204

Até esta versão, o endpoint retornava 204 No Content. Agora ele retorna 200 OK com o corpo JSON documentado acima, para que toda exclusão informe o seu face_retention_outcome. Atualize os clientes que verificam 204. O comportamento padrão não mudou: as aplicações existentes continuam em delete_with_session, e nenhuma migração ativa a retenção por você. Ative-a explicitamente no Console ou por meio de PATCH /v3/webhook/.

Relacionados

Autorizações

x-api-key
string
header
obrigatório

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.

Parâmetros de caminho

sessionId
string<uuid>
obrigatório

UUID (session_id) da sessão de Verificação de usuários (KYC) ou de Verificação de empresas (KYB) a ser excluída, conforme retornado na criação da sessão. Deve ser um UUID canônico com hifens: um valor que não seja UUID não corresponde à rota e retorna 404.

Exemplo:

"11111111-2222-3333-4444-555555555555"

Corpo

application/json

Opcional. Omita o corpo inteiro para seguir a política de retenção da aplicação com uma exclusão operacional.

retain_face_embeddings
boolean | null

Substitui a face_retention_policy da aplicação para esta exclusão. true mantém um template biométrico facial sem imagem vinculado ao User da sessão após a exclusão da sessão; false exclui o embedding facial junto com a sessão; omita ou use null para seguir a política da aplicação. Ignorado para sessões KYB e para sessões sem embedding facial.

Exemplo:

true

face_retention_days
integer

Duração finita de retenção, em dias, de um template biométrico retido. Obrigatório quando um template é retido, a menos que a aplicação já defina face_retention_days. O expires_at do template é o mais próximo entre essa duração, o período geral de retenção de dados da aplicação e face_retention_deadline.

Intervalo obrigatório: 1 <= x <= 3650
Exemplo:

365

face_retention_deadline
string<date-time>

Expiração definitiva opcional para um template retido. Deve estar no futuro.

Exemplo:

"2027-08-28T00:00:00Z"

deletion_instruction
enum<string>
padrão:operational_session_delete

A classe de instrução que você está dando. operational_session_delete exclui a sessão e retém um template apenas quando a política ou retain_face_embeddings assim determina. privacy_erasure elimina todos os templates biométricos retidos vinculados ao User da sessão antes de excluir a sessão, não pode ser substituído pela política da aplicação e não pode ser combinado com retain_face_embeddings: true (400).

Opções disponíveis:
operational_session_delete,
privacy_erasure
Exemplo:

"operational_session_delete"

instruction_id
string

Sua referência permanente para esta instrução de exclusão (por exemplo, o ID de um ticket de apagamento). Registrada na trilha de auditoria e em qualquer template retido. Gerada pela Didit quando omitida.

Maximum string length: 255
Exemplo:

"dsar-2026-0142"

Resposta

Sessão excluída. O corpo informa o que aconteceu com os dados biométricos faciais da sessão e, para uma sessão KYB, quantas verificações criadas por ela foram excluídas junto.

session_id
string<uuid>

A sessão excluída.

session_number
integer | null

O número da sessão excluída.

face_retention_outcome
enum<string>

O que aconteceu com os dados biométricos faciais da sessão. deleted: o embedding facial foi excluído junto com a sessão (padrão). retained_with_user: a sessão é excluída e um template biométrico sem imagem permanece vinculado ao User; veja biometric_template_uuid. none: a sessão não tinha embedding facial (por exemplo, uma sessão de KYB ou uma sessão de KYC sem selfie de prova de vida). ineligible_no_vendor_user: a retenção foi solicitada, mas a sessão não tem um User vinculado, então o embedding foi excluído junto com a sessão. Uma falha no armazenamento biométrico nunca é informada por este campo neste endpoint: ele retorna 503 e a sessão não é excluída.

Opções disponíveis:
retained_with_user,
deleted,
none,
ineligible_no_vendor_user
biometric_template_uuid
string<uuid> | null

Id do template biométrico retido quando face_retention_outcome é retained_with_user; caso contrário, null. Gerencie-o por meio de /v3/biometric-templates/{template_uuid}/.

biometric_template_expires_at
string<date-time> | null

Quando o template biométrico retido é excluído, quando face_retention_outcome é retained_with_user; null quando nenhum template é retido.

deleted_child_verifications
integer

Para uma sessão de Verificação de empresas (KYB): quantas verificações criadas por ela (as sessões de KYC das suas pessoas-chave e as sessões de KYB dos seus proprietários corporativos, recursivamente) foram excluídas junto com ela. Sempre 0 para uma sessão de KYC.

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