Saltar para o conteúdo principal
GET
cURL

​
Suporte a KYC e KYB

Este endpoint funciona tanto para sessões de Verificação de utilizadores (KYC) como de Verificação de empresas (KYB). A resposta inclui sempre um campo session_kind de nível superior:
  • "user": sessão de Verificação de utilizadores (KYC). A resposta contém id_verifications, liveness_checks, face_matches, nfc_verifications, poa_verifications, database_validations.
  • "business": sessão de Verificação de empresas (KYB). A resposta contém registry_checks, document_verifications, key_people_checks.
Os dois tipos partilham aml_screenings, phone_verifications, email_verifications, questionnaire_responses, ip_analyses, document_ai_documents, bank_verifications, reviews, contact_details, além dos campos comuns de nível superior (session_id, session_number, session_url, status, workflow_id, vendor_data, metadata, callback, features, expected_details, created_at, expires_at). A Didit procura o session_id nos dois tipos de sessão (primeiro nas sessões de Verificação de utilizadores, depois nas de Verificação de empresas) e devolve a que corresponder. Os UUIDs são únicos por aplicação, pelo que não há ambiguidade. Consulte a visão geral das sessões para ver a matriz completa de funcionalidades específicas de cada tipo.

​
Exemplos

Resposta (truncada):

​
Tratamento da resposta do seu lado

​
Estado, rastreio da decisão e campos de revisão

Cada decisão explica como o respetivo status foi atingido.

​
Conservação de dados biométricos

biometric_retention está sempre presente. deletes_at é a data em que os dados biométricos ativos da sessão são eliminados, e jurisdictions lista os estados dos EUA cujas regras biométricas definem um limite de eliminação para a pessoa (US quando o estado é desconhecido). deletes_at é null quando ainda não se aplica nenhuma data.

​
Verificação de localização

Quando o fluxo tem um passo de Verificação de localização, a decisão inclui dois arrays. geolocation_checks[] tem um item por passo: a sua tentativa aceite, com o resultado, as coordenadas e a respetiva precisão, as verificações face à localização do IP e à morada registada, e os warnings do passo. geolocation_attempts[] lista todas as tentativas de todos os passos, das mais antigas para as mais recentes, com o momento em que cada uma foi recebida. Os fluxos sem o passo devolvem ambos como null. Todos os campos e resultados estão no relatório de Verificação de localização.

​
Eventos de encaminhamento do fluxo

?include=events acrescenta a cronologia de eventos da sessão. Para além das alterações de passo e de estado, um fluxo que encaminha através de nós de ramificação deixa um evento por cada decisão de encaminhamento. Assim, uma integração (ou a cronologia da Consola) consegue explicar porque é que uma sessão terminou num determinado resultado, sem ter de reproduzir manualmente o grafo do fluxo: Ambos os eventos incluem sent_at em milissegundos, como todos os outros eventos, e não têm component, feature_step nem step: provêm do motor do fluxo, e não do dispositivo do utilizador. Uma ramificação “else” (uma ramificação sem condições) conta como ramificação correspondente; fallback só é true quando nada correspondeu. Os nós com uma única ligação de saída não tomam decisão e não deixam evento. A mesma estrutura também devolve workflow_terminal_node_id: o node_id do último nó de estado do fluxo registado que definiu um estado da sessão, ou null se não tiver sido registado nenhum ID de nó desse tipo. Trata-se da proveniência histórica do fluxo. As aprovações manuais, as recusas e os reenvios não o limpam; um nó de estado do fluxo posterior substitui-o. Por exemplo, se um fluxo encaminhar uma sessão para um nó Em análise e um revisor a aprovar mais tarde, o status atual é Approved, enquanto workflow_terminal_node_id continua a identificar o nó Em análise. Pode também continuar preenchido enquanto um reenvio está em curso. Para distinguir os resultados do fluxo das decisões manuais posteriores, consulte o status atual e as cronologias de eventos e de activity_reviews.

​
Submissões anteriores (?include=resubmissions)

Um reenvio devolve o utilizador aos passos que selecionar e mantém o que esses passos devolveram antes. ?include=resubmissions acrescenta um array resubmissions, do mais antigo para o mais recente, com uma entrada por cada pedido de reenvio. Cada entrada inclui os resultados que esse pedido substituiu, para que possa consultar sempre o que o utilizador submeteu anteriormente. Funciona para sessões de utilizadores (KYC) e de empresas (KYB), e pode combiná-lo com eventos (?include=events,resubmissions). Sem o parâmetro, a resposta não muda. Os resultados atuais (id_verifications e os restantes ao nível superior) descrevem sempre a submissão mais recente. Os passos que não foram devolvidos mantêm aí um único resultado.
Eliminar uma sessão elimina os resultados de todas as submissões associadas a ela.

​
Métodos de verificação de identidade

Cada item de id_verifications[] indica qual dos três métodos de Verificação de identidade o produziu, para que consiga distinguir uma leitura de documento de uma consulta a um registo ou de um início de sessão com carteira, sem ter de adivinhar a partir dos campos que, por acaso, estão preenchidos: Uma sessão de documento indica document e documentary e deixa os restantes campos como null, pelo que as integrações existentes não precisam de alterações. Os tipos de cada campo estão em Modelos de dados.

​
Consentimento biométrico

As decisões de Verificação de utilizadores incluem um objeto biometric_consent: se a sessão exigiu consentimento biométrico explícito, o trigger que o exigiu, o status da resposta e a respetiva prova. Dois valores indicam que o consentimento não foi recolhido: Quando o passo aparece e o que significa cada valor estão descritos em Consentimento biométrico; todos os campos estão em Modelos de dados.

​
Verificação bancária

Quando o fluxo tem um passo de Verificação bancária, a decisão inclui bank_verifications[], em ambos os tipos de sessão: um item por passo, com o valor null até que um passo produza um. Para distinguir o início de sessão no banco da verificação da conta, leia method, e não ownership.method: ownership.method é a comparação de nomes que produziu a pontuação. Todos os campos estão no esquema BankVerificationResult da resposta deste endpoint.

​
Assinatura eletrónica

Quando o fluxo tem um passo de Assinatura eletrónica, a decisão inclui signatures[], em ambos os tipos de sessão. Há um item por signatário: um para uma Verificação de utilizadores e um por cada pessoa-chave que assina numa Verificação de empresas (KYB). Os fluxos sem este passo não devolvem de todo a chave. Transfira os ficheiros a partir dos caminhos, com a sua chave de API. Consulte o Relatório de assinatura eletrónica para ver todos os campos.

​
Erros

​
Relacionados

Autorizações

​
x-api-key
string
header
obrigatório

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.

Parâmetros de caminho

​
sessionId
string<uuid>
obrigatório

UUID da sessão de verificação cuja decisão pretende obter. Este é o session_id retornado por POST /v3/session/. O mesmo caminho funciona para sessões de Verificação de utilizadores (KYC) e de Verificação de empresas (KYB) — o servidor resolve o ID em ambos os tipos de sessão.

Deve ser um UUID válido. A rota apenas faz correspondência com UUIDs bem formatados, pelo que um valor mal formatado é rejeitado pelo router de URL antes da execução de qualquer código da aplicação e a resposta é uma página HTML de 404 em vez do envelope JSON {"detail": ...} apresentado abaixo. Valide o formato do UUID no lado do cliente para que possa distinguir um erro de introdução de dados de um verdadeiro 404 de sessão em falta.

Exemplo:

"11111111-2222-3333-4444-555555555555"

Parâmetros de consulta

​
include
enum<string>

Lista separada por vírgulas de secções adicionais do payload. Valores suportados: events e resubmissions, isolados ou em conjunto (events,resubmissions). Quando include=events é transmitido, a resposta contém adicionalmente a cronologia de eventos da sessão (events, incluindo os eventos de encaminhamento WORKFLOW_BRANCH_EVALUATED / WORKFLOW_STATUS_NODE_REACHED descritos na página Obter sessão), o registo de atividade completo (activity_reviews), indicadores de lista de bloqueio (blocklisted), um cost_breakdown por sessão, metadados do fluxo (workflow_type, workflow_version, workflow_version_id e workflow_terminal_node_id - o último nó de estado do fluxo registado que definiu um estado de sessão, ou null se nenhum tiver sido registado; proveniência histórica que não é limpa por aprovações manuais, recusas ou novos envios, sendo substituída por um nó de estado do fluxo posterior) e metadados da sessão (api_service — string ou null, definido apenas para sessões de API autónoma; session_type — API, HOSTED ou MIGRATED; has_device_nfc_support — booleano). Dois campos mudam em relação à estrutura simples: o discriminador session_kind de nível superior é omitido (a estrutura de eventos existe apenas para sessões de utilizador) e o array features passa de strings simples para objetos {feature, node_id} — onde a funcionalidade de e-mail é comunicada como EMAIL em vez de EMAIL_VERIFICATION. Esta estrutura expandida é utilizada principalmente pela consola da Didit; a maioria das integrações de API deve omitir o parâmetro. Limitação de KYB: include=events aplica-se apenas a sessões de utilizador (KYC). As sessões de empresas (session_kind = "business") devolvem sempre a estrutura normal de decisão de empresa — events, activity_reviews, blocklisted, cost_breakdown e os metadados adicionais de workflow_*/sessão nunca são devolvidos para sessões de empresas, e o respetivo array features permanece um array simples de strings. Com include=resubmissions (tanto em sessões de utilizador como de empresas), a resposta também contém resubmissions: uma entrada por pedido de novo envio, do mais antigo para o mais recente, cada uma com number, created_at, previous_status, nodes, reasons, requested_by e results (o que os passos reenviados devolveram antes do pedido, sob as mesmas chaves e com a mesma estrutura dos resultados atuais). Cada item de cost_breakdown contém usage_type, price, details e created_at: um passo reenviado que seja executado novamente é faturado como um novo item.

Opções disponíveis:
events,
resubmissions,
events,resubmissions
Exemplo:

"events"

Resposta

Relatório completo de decisão. session_kind distingue as duas estruturas: sessões user contêm os arrays de funcionalidades de KYC apresentados abaixo; sessões business contêm, em vez disso, registry_checks, document_verifications e key_people_checks juntamente com os arrays partilhados. Os arrays de funcionalidades são null até que o fluxo tenha executado essa funcionalidade; os URLs dos ficheiros multimédia são ligações pré-assinadas de curta duração.

​
session_id
string<uuid>

O identificador único da sessão.

​
session_kind
enum<string>

Discriminador que indica se esta é uma sessão de Verificação de utilizadores (KYC) ou de Verificação de empresas (KYB). Quando for user, aplicam-se os arrays de funcionalidades de KYC (id_verifications, nfc_verifications, liveness_checks, face_matches, poa_verifications, document_ai_documents, database_validations, ...) e os arrays da empresa estão ausentes. Quando for business, o payload inclui registry_checks, document_verifications, key_people_checks, além dos arrays partilhados (aml_screenings, phone_verifications, email_verifications, ip_analyses, questionnaire_responses). Omitido quando include=events é transmitido — a estrutura de eventos apenas existe para sessões de utilizador, pelo que o discriminador é removido nessa variante.

Opções disponíveis:
user,
business
​
shared_from_session
string<uuid> | null

Para uma sessão clonada com POST /v3/session/import-shared/: o session_id da sessão original na aplicação de origem. null para qualquer outra sessão. Omitido quando include=events é especificado.

​
shared_from_session_number
integer | null

session_number da sessão de origem quando esta sessão foi importada de outra aplicação da sua organização. Caso contrário, null.

​
session_number
integer | null

O número da sessão.

​
session_url
string<uri> | null

O URL da sessão.

​
status
enum<string>

Estado global do ciclo de vida da sessão — o resultado agregado do fluxo. Os valores finais são Approved, Declined, In Review, Expired, Kyc Expired e Abandoned; Not Started, In Progress, Awaiting User e Resubmitted indicam que a sessão ainda está a avançar no fluxo.

Opções disponíveis:
Not Started,
In Progress,
Awaiting User,
In Review,
Approved,
Declined,
Resubmitted,
Expired,
Kyc Expired,
Abandoned
​
status_override
object | null

Presente quando um revisor definiu status manualmente. null quando o estado é automático. Utilize-o para distinguir uma aprovação manual de uma automática.

​
decision_trace
object

Como o estado foi alcançado: quem o definiu e que avisos o originaram.

​
linked_records
object | null

Um resumo de outros registos associados à sessão. null quando não há nada a apresentar e para fluxos que declarem um padrão de garantia de idade.

​
workflow_id
string<uuid> | null

Identificador estável do grupo de fluxos que gerou esta sessão. Os fluxos são versionados — este valor identifica o fluxo em si, e não a versão específica.

​
features
string[]

Lista de funcionalidades de verificação configuradas para esta sessão, como nomes de apresentação: ID_VERIFICATION, NFC, LIVENESS, FACE_MATCH, POA, PHONE, EMAIL_VERIFICATION, AML, IP_ANALYSIS, DATABASE_VALIDATION, QUESTIONNAIRE, AGE_ESTIMATION, FACE_SEARCH, GEOLOCATION (verificação de localização) (as sessões de Verificação de empresas (KYB) utilizam o conjunto de funcionalidades de KYB: KYB_REGISTRY, KYB_DOCUMENTS, KYB_KEY_PEOPLE, AML, PHONE, EMAIL_VERIFICATION, IP_ANALYSIS, QUESTIONNAIRE). Com include=events, cada entrada torna-se um objeto {feature, node_id} em vez de uma string simples, e a funcionalidade de e-mail é renomeada: aparece como EMAIL no modo de eventos em vez do EMAIL_VERIFICATION aqui utilizado.

A funcionalidade da sessão.

​
vendor_data
string | null

Os dados de fornecedor da sessão.

​
metadata
object | null

Os metadados da sessão.

​
expected_details
object | null

Dados esperados fornecidos na criação da sessão — utilizados para validação cruzada com os dados extraídos (KYC) ou para pré-preencher a pesquisa no registo de empresas (KYB). Devolve exatamente as mesmas chaves que foram fornecidas; null quando nenhum dado foi fornecido. As sessões de KYC contêm os campos da pessoa; as sessões de empresas (KYB) contêm company_name, registry_country e registration_number.

​
contact_details
object | null

Detalhes de contacto fornecidos quando a sessão foi criada (utilizados para e-mails de notificação, verificação pré-preenchida de telefone/e-mail e idioma de comunicação). null quando não foi fornecido nem um e-mail nem um número de telefone.

​
callback
string<uri> | null

O URL de retorno da sessão.

​
id_verifications
object[] | null

Array de relatórios de verificação de identidade (OCR) produzidos por passos de documento de identificação no grafo do fluxo. Sempre um array JSON — leia id_verifications[0] e itere se o seu fluxo puder executar mais do que uma verificação de identificação (por exemplo, uma verificação principal mais uma verificação adicional). null até que pelo menos um passo de identificação tenha produzido dados. Cada item é o relatório completo, incluindo node_id, status ao nível da funcionalidade, campos do documento extraídos, URLs de imagens, pontuações de qualidade, MRZ, análise da morada, correspondências entre sessões e warnings[].

​
nfc_skip_reason
enum<string> | null

O motivo pelo qual a verificação do chip NFC não foi executada, preenchido sempre que o fluxo incluir um passo de NFC. null enquanto o NFC estiver pendente ou quando o chip tiver sido efetivamente lido. Valores: USER_SKIPPED - o utilizador optou por ignorar num dispositivo compatível com NFC (permitido por allow_nfc_skip); DOCUMENT_WITHOUT_CHIP - o documento não possui nenhum chip NFC legível (não é um documento eletrónico ICAO 9303); CHIP_CERTIFICATE_UNAVAILABLE - o certificado de assinatura do país emissor (CSCA) que abrange o período de emissão do documento não está disponível, pelo que a assinatura do chip não pode ser verificada; DEVICE_WITHOUT_NFC - o dispositivo indicou que não tem leitor NFC; INTEGRATION_WITHOUT_NFC_ACCESS - a verificação foi executada sem um SDK nativo (por exemplo, num navegador web), que não tem acesso ao leitor NFC do telemóvel; MRZ_KEY_UNAVAILABLE - não foi possível obter a chave de acesso ao chip a partir da MRZ do documento; JPKI_UNAVAILABLE - o documento é um Japan My Number Card, cujo chip é lido através de JPKI, e o JPKI não estava disponível para esta verificação: não está ativado, ou o SDK nativo da aplicação não consegue ler My Number Cards.

Opções disponíveis:
USER_SKIPPED,
DOCUMENT_WITHOUT_CHIP,
CHIP_CERTIFICATE_UNAVAILABLE,
DEVICE_WITHOUT_NFC,
INTEGRATION_WITHOUT_NFC_ACCESS,
MRZ_KEY_UNAVAILABLE,
JPKI_UNAVAILABLE
​
nfc_verifications
object[] | null

Array de relatórios de NFC / passaporte eletrónico produzidos por passos de NFC no grafo do fluxo. Isto é sempre um array JSON, nunca um objeto nfc singular — leia nfc_verifications[0] e itere se o seu fluxo puder executar NFC mais do que uma vez. null até que pelo menos um passo de NFC tenha produzido dados. Cada item é o relatório completo, incluindo node_id, status ao nível da funcionalidade, chip_protocol, chip_data, authenticity (integridade de SOD + DG), certificate_summary e warnings[]. O cartão My Number do Japão é lido através de JPKI em vez do ICAO 9303: o seu item tem chip_protocol: "jpki", contém as suas evidências em jpki e deixa os campos ICAO a null. Quando o passo de NFC foi ignorado antes de poder ser oferecido (documento sem chip, certificado em falta, nenhuma capacidade NFC reportada, chave MRZ ilegível, JPKI indisponível para um cartão My Number), este permanece null e nfc_skip_reason explica o motivo; ignorar no próprio passo (o utilizador tocou em «Ignorar», ou o leitor revelou-se indisponível no momento da leitura) continua a produzir um relatório com is_nfc_skipped: true.

​
liveness_checks
object[] | null

Array de relatórios de prova de vida produzidos por passos de prova de vida no grafo do fluxo. Sempre um array JSON — nunca um objeto liveness singular. null até que pelo menos um passo de prova de vida tenha produzido dados. Cada item é o relatório completo, incluindo node_id, status ao nível da funcionalidade, method, score, reference_image, video_url, age_estimation opcional, matches[] entre sessões e warnings[].

​
face_matches
object[] | null

Array de relatórios de correspondência facial produzidos por passos de correspondência facial no grafo do fluxo. Sempre um array JSON — nunca um objeto face_match singular. null até que pelo menos um passo de correspondência facial tenha produzido dados. Cada item é o relatório completo, incluindo node_id, status ao nível da funcionalidade, score de similaridade, source_image, target_image e warnings[].

​
phone_verifications
object[] | null

Array de relatórios de verificação de telefone — sempre um array JSON, nunca um objeto phone singular. null até que pelo menos um passo de telefone tenha produzido dados. Cada item é o relatório completo, incluindo node_id, status ao nível da funcionalidade, o número de telefone e metadados do país, lifecycle[], matches[] e warnings[].

​
email_verifications
object[] | null

Array de relatórios de verificação de e-mail — sempre um array JSON, nunca um objeto email singular. null até que pelo menos um passo de e-mail tenha produzido dados. Cada item é o relatório completo, incluindo node_id, status ao nível da funcionalidade, o endereço de e-mail, dados de violações de segurança, lifecycle[], matches[] e warnings[].

​
poa_verifications
object[] | null

Array de relatórios de Comprovativo de morada (POA) — sempre um array JSON, nunca um objeto poa singular. null até que pelo menos um passo de POA tenha produzido dados. Cada item é o relatório completo, incluindo node_id, status ao nível da funcionalidade, o URL do ficheiro do documento, emissor, datas, morada analisada e warnings[].

​
document_ai_documents
object[] | null

Relatórios do Document AI agrupados por nó do fluxo — sempre um array JSON, nunca um objeto singular. null até que pelo menos um passo do Document AI tenha produzido dados. Presente apenas quando session_kind = user. Cada item é um grupo de nós com um status agregado, o node_id, um array items[] dos resultados por documento (dados extraídos indexados pela chave de campo configurada) e warnings.

​
questionnaire_responses
object[] | null

Array de relatórios de respostas a questionários — sempre um array JSON, nunca um objeto questionnaire singular. null até que pelo menos um passo de questionário tenha produzido dados. Cada item é o relatório completo, incluindo node_id, os metadados do questionário, secções com elementos de formulário e as respostas do utilizador.

​
bank_verifications
object[] | null

Resultados da Verificação bancária, um item por passo de Verificação bancária, para Verificação de utilizadores e Verificação de empresas (KYB). null até que um passo produza um. O method de cada item indica como a conta foi verificada: open_banking (início de sessão bancário) ou account_lookup (verificação de conta), ou uma alternativa por statement ou microdeposits, e none quando a pessoa continuou sem banco antes de qualquer tentativa ser avaliada (continued_without_bank). Consulte Métodos de verificação bancária.

​
signatures
object[]

Resultados da Assinatura eletrónica, um item por signatário e passo de assinatura, para Verificação de utilizadores e Verificação de empresas. Presente apenas quando o fluxo tem um passo de Assinatura eletrónica; uma matriz vazia até que um signatário o atinja. Consulte o Relatório de assinatura eletrónica.

​
aml_screenings
object[] | null

Array de relatórios de triagem AML — sempre um array JSON, nunca um objeto aml no singular. null até que pelo menos um passo de AML tenha produzido dados. Cada item é o relatório completo, incluindo node_id, status ao nível da funcionalidade, total_hits, entity_type, hits[], score, screened_data, is_ongoing_monitoring_enabled e warnings[].

​
ip_analyses
object[] | null

Array de relatórios de Análise de dispositivo e IP — sempre um array JSON, nunca um objeto ip_analysis singular. null até que pelo menos um passo de análise de IP tenha produzido dados. Cada item é o relatório completo, incluindo node_id, status ao nível da funcionalidade, dados de IP e geolocalização, impressão digital do dispositivo e warnings[]. As entradas com (node_id, ip_address, device_fingerprint) duplicados são deduplicadas no servidor.

​
geolocation_checks
object[] | null

Array de resultados de verificação de localização, um por passo de verificação de localização: a tentativa aceite desse passo. null até que um passo de verificação de localização tenha produzido dados. As tentativas anteriores do mesmo passo estão em geolocation_attempts.

​
geolocation_attempts
object[] | null

Cada tentativa de cada passo de verificação de Localização desta sessão, da mais antiga para a mais recente. As tentativas substituídas por um novo envio são excluídas. Um fluxo que omita geolocation_checks através dos respetivos atributos de resposta também omite esta lista.

​
database_validations
object[] | null

Array de relatórios de Validação de base de dados — sempre um array JSON, nunca um objeto database_validation singular. null até que pelo menos um passo de validação de base de dados tenha gerado dados. Cada item é o relatório completo, incluindo node_id, o status ao nível da funcionalidade, screened_data, as validations[] por serviço (cada uma com o seu source_data do registo) e warnings[]. Os campos screened_data e source_data variam por país:

ARG (Argentina): screened_data: {document_number, selfie, gender, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, date_of_death, tax_id, tax_id_type, face_match_score, sit_1_since, banks, last_position, highest_position, rejected_checks}. Utiliza a validação biométrica de correspondência facial do RENAPER. O género é inferido automaticamente a partir da análise facial ou do nome próprio quando não se encontra presente no documento (por exemplo, em cartas de condução)

BOL (Bolívia): screened_data: {document_number, date_of_birth, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, gender}

BRA (Brasil): screened_data: {tax_number, first_name, last_name, date_of_birth}. source_data inclui sempre {identification_number, first_name, last_name, date_of_birth, lgpd_minor, minor_under_18, minor_under_16} para correspondências bem-sucedidas de CPF. Consultas de adultos bem-sucedidas definem esses sinalizadores como false. O serviço Consulta CPF da Receita Federal pode devolver HTTP 422 (menor de 18 anos) ou 451 (menor de 16 anos) com dados retidos pela LGPD; nesses casos, source_data define os sinalizadores de menor como true conforme apropriado, inclui o código de estado HTTP do serviço a montante e a validação ao nível do campo é no_match. Consulte a secção do Brasil da referência de Códigos de Resultado de Validação de base de dados para a lista completa de códigos.

CHL (Chile): screened_data: {personal_number, first_name, last_name, date_of_birth}. source_data: {identification_number, first_name, last_name, date_of_birth, gender}

COL (Colômbia): screened_data: {document_number, document_type, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, document_type}

CRI (Costa Rica): screened_data: {personal_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

DOM (República Dominicana): screened_data: {personal_number}. source_data: {identification_number} (devolve apenas valid/invalid)

ECU (Equador): screened_data: {personal_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, street, formatted_address, gender, nationality, education, marital_status, spouse, mother_name, father_name, profession}

ESP (Espanha): screened_data: {personal_number, document_type, expiration_date, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, document_type, expiration_date}

GTM (Guatemala): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

HND (Honduras): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

MEX (México): screened_data: {personal_number (CURP), first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, gender, nationality, curp_status, state_of_birth, doc_probatorio, registration_year, registration_state, registration_municipality, num_acta, crip, issuing_state_code, foreign_registry_number, folio_carta, folio_certificado}. Utiliza o registo civil do RENAPO. Está também disponível um serviço independente de verificação de validade do INE para o MEX como uma validação adicional individual.

PAN (Panamá): screened_data: {personal_number, selfie}. source_data: {identification_number}. Utiliza a validação biométrica do SIB

PER (Peru): screened_data: {personal_number (DNI), first_name, last_name}. source_data: {identification_number, first_name, last_name, paternal_name, maternal_name, verification_number, verification_letter}

PRY (Paraguai): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

SLV (El Salvador): screened_data: {document_number, date_of_birth, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

URY (Uruguai): screened_data: {personal_number, date_of_birth, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

VEN (Venezuela): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, gender, date_of_birth, document_type}

​
database_validation_not_performed_reason
object | null

O motivo pelo qual uma validação de base de dados configurada não produziu nenhum resultado, como {code, message} mais campos de contexto. Presente apenas quando database_validations é null num fluxo que tem o passo, para que possa distinguir "o registo concordou" de "nada foi executado". null nos restantes casos.

​
reviews
object[]
​
assignee
object | null

O revisor da consola ao qual a sessão está atribuída, ou null quando não está atribuída a ninguém.

​
waiting_since
string<date-time> | null

Quando a sessão começou a aguardar revisão. null a menos que a sessão esteja In Review e a sua aplicação defina um prazo de revisão.

​
sla_due_at
string<date-time> | null

Quando a revisão deve ser concluída. null a menos que a sessão esteja In Review e a sua aplicação defina um prazo de revisão.

​
created_at
string<date-time>

Carimbo de data/hora em que a sessão foi criada (ISO 8601, UTC).

​
expires_at
string<date-time> | null

Carimbo de data/hora em que esta sessão está agendada para expirar. Definido em sessões de Verificação de utilizadores (KYC) quando foi configurada uma expiração no momento da criação (ou assim que o estado Approved acionar o cálculo de expiração do KYC). null para sessões sem uma expiração configurada e para tipos que não utilizam expiração (por exemplo, sessões de Verificação de empresas (KYB) que nunca receberam um expires_at).

​
registry_checks
object[] | null

Verificações no registo de empresas. Presente apenas quando session_kind = business. Cada item contém o payload completo do registo de empresas.

​
key_people_checks
object[] | null

Verificações agregadas de pessoas-chave. Presente apenas quando session_kind = business. Cada item usa o formato de dois contentores (registry, submitted, ubo_kyc_summary).

​
document_verifications
object[] | null

Verificações de documentos agrupadas por nó do fluxo. Presente apenas quando session_kind = business.

​
environment
enum<string>

Se a sessão foi criada por uma aplicação em produção (live) ou por uma aplicação sandbox (sandbox). As sessões sandbox são gratuitas, totalmente simuladas e nunca consomem créditos.

Opções disponíveis:
live,
sandbox
​
sandbox_scenario
string | null

O cenário de sandbox com o qual a sessão foi criada. null para sessões de produção e para sessões de sandbox criadas sem nenhum.

​
resubmissions
object[]

Retornado apenas com include=resubmissions, para sessões de utilizador e de empresa. Uma entrada por pedido de nova submissão, da mais antiga para a mais recente. Cada entrada contém os resultados que os passos ressubmetidos retornaram antes do pedido, para que as submissões anteriores permaneçam legíveis. A eliminação da sessão elimina todas as submissões.

​
biometric_consent
object | null

Se a sessão exigiu consentimento biométrico explícito antes de uma captura facial, o motivo e a evidência da resposta. Apenas sessões de Verificação de utilizadores (KYC); o mesmo objeto está na decision dos webhooks da sessão. null quando a sessão nunca foi avaliada, por exemplo, num fluxo sem captura facial. Campos sem valor registado são null. Um SDK nativo anterior à versão 4.10.0, ou um que não reporte a sua versão, não consegue apresentar o passo de consentimento: as respetivas capturas faciais são executadas como anteriormente, e uma sessão que tenha exigido consentimento reporta status: "pending" com reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK". Consulte Consentimento biométrico.

​
investigator
object | null

A revisão mais recente do Investigator sobre o item, ou nulo se nunca tiver tido nenhuma. Transmitida pela decisão da sessão V3 e da sessão empresarial (e, portanto, por webhooks status.updated).

​
biometric_retention
object

Quando os dados biométricos em tempo real desta sessão são eliminados.

​
fraud_check
object | null

O resultado de uma chamada à API Fraud Check. null para qualquer outra sessão.

​
full_session_video
string<uri> | null

URL temporário da gravação completa da sessão. Devolvido apenas quando a sua organização grava vídeo da sessão completa.

​
full_session_video_recorded_at
string<date-time> | null

Quando a gravação de sessão completa foi feita. Devolvido apenas quando a sua organização grava vídeo de sessão completa.

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