Pular para o conteúdo principal

Visão geral

Todo relatório por recurso segue o formato do serializer V3 definido em service-didit-verification. O mesmo objeto aparece em três lugares, e por isso o schema mostrado aqui é a única fonte de verdade para todos eles:
  • GET /v3/session/{sessionId}/decision/: cada recurso é retornado como um array no plural (id_verifications[], nfc_verifications[], liveness_checks[], face_matches[], poa_verifications[], phone_verifications[], email_verifications[], aml_screenings[], ip_analyses[], database_validations[], questionnaire_responses[], signatures[], bank_verifications[] (veja Métodos de verificação bancária) e os equivalentes de KYB registry_checks[], document_verifications[], key_people_checks[]).
  • Payloads de webhook (status.updated, data.updated): o mesmo formato, dentro do envelope decision.
  • APIs independentes: as respostas de objeto único (Busca facial, Estimativa de idade, Autenticação biométrica) reutilizam o mesmo conjunto de campos.
A V3 introduziu fluxos de verificação (workflows) com múltiplas instâncias: cada objeto de recurso traz um node_id que vincula o relatório ao nó do grafo do fluxo que o gerou. Os endpoints V2 (no singular: kyc, face, aml etc.) continuam retrocompatíveis, mas retornam apenas a primeira instância.

Campos comuns

Todo objeto de relatório expõe os seguintes campos: Os campos de mídia (portrait_image, front_image, document_file, …) são URLs pré-assinadas com um período de validade limitado: baixe os arquivos logo, em vez de armazenar a URL. Os exemplos as mostram como https://<media-host>/....

Objeto de aviso

Retornado em cada array warnings[]. Schema de logs/serializers/log.py:8-65 (LogV3Serializer).

Objetos de relatório

As seções restantes descrevem cada objeto de relatório por recurso. O texto do título H3 é mantido fixo de propósito, para que outras documentações possam linkar diretamente para ele.

Verificação de identidade

Retornado para cada documento de KYC/identidade enviado pelo usuário. Aparece como id_verifications[] em GET /v3/session/{sessionId}/decision/ e dentro do campo kyc das respostas V2. Fonte: kyc/serializers/kyc.py:383-414 (IDVerificationV3Serializer, que estende IDVerificationV2Serializer em kyc/serializers/kyc.py:320-380).
O mesmo objeto com um método diferente de documento. Apenas as chaves específicas do método mudam: tudo o que a leitura de um documento preenche é preenchido com o registro da fonte ou os atributos da carteira, e as chaves que não se aplicam ficam como null.

Verificação NFC

Retornada para cada leitura de chip em um documento de identidade: um chip ePassport ou eID conforme ICAO 9303, ou um Japan My Number Card lido via JPKI (chip_protocol: "jpki"). Aparece como nfc_verifications[] em GET /v3/session/{sessionId}/decision/ (um por registro KYC pai). Fonte: kyc/serializers/epassport.py:121-139 (NFCV3Serializer, estende NFCV2Serializer em kyc/serializers/epassport.py:83-118).

Verificação de prova de vida

Retornado para cada sessão de prova de vida. Aparece como liveness_checks[] em GET /v3/session/{sessionId}/decision/. Fonte: face/serializers/face.py:301-320 (LivenessV3Serializer, estende LivenessV2Serializer em face/serializers/face.py:216-298).
Uma sessão PASSIVE retorna este campo quando a captura armazenou uma gravação, e null quando a sessão não manteve gravação; o exemplo acima é de uma sessão que não manteve nenhuma.

Correspondência facial

Retornado para cada comparação facial (normalmente o rosto da prova de vida do usuário com o retrato do documento). Aparece como face_matches[] em GET /v3/session/{sessionId}/decision/. Fonte: face/serializers/face.py:367-389 (FaceMatchV3Serializer, estende FaceMatchV2Serializer em face/serializers/face.py:323-364).

Busca facial

Retornado pela API independente de Busca facial (POST /v3/face-search/). A busca facial nunca aparece como um array de vários itens em /v3/session/{sessionId}/decision/. Quando persistida com save_api_request=true, a sessão aparece ali como uma entrada FACE_SEARCH em features[], mais um item em liveness_checks[] que contém os matches armazenados. Fontes: apis/serializers/face_search.py:8-79 (FaceSearchResponseSerializer, que encapsula FaceSearchDetailsSerializer); os dicionários de correspondência são montados em face/utils/utils.py:869-884. Resposta de nível superior: Objeto face_search:

Objeto de correspondência de busca facial

Análise AML

Retornado para cada entidade analisada. Aparece como aml_screenings[] em GET /v3/session/{sessionId}/decision/, tanto para sessões KYC quanto para sessões KYB. Fonte: aml/serializers/aml.py:63-85 (AMLV3Serializer, que estende AMLV2Serializer em aml/serializers/aml.py:28-60).

Análise de IP

Retornada para cada localização de rede capturada. Aparece como ip_analyses[] em GET /v3/session/{sessionId}/decision/ para sessões de KYC e de KYB. Origem: kyc/serializers/location.py:196-243 (IPAnalysisSerializerV3).

Verificação de localização

Retornado para cada etapa de Verificação de localização. Aparece como geolocation_checks[] em GET /v3/session/{sessionId}/decision/: um item por etapa, correspondente à tentativa aceita. geolocation_attempts[] lista todas as tentativas de todas as etapas, da mais antiga para a mais recente. Ambos são null em fluxos sem a etapa. Origem: GeolocationDecisionSerializer. Todos os campos e exemplos estão no relatório de verificação de localização.

Comprovante de endereço

Retornado para cada documento de comprovante de endereço enviado. Aparece como poa_verifications[] em GET /v3/session/{sessionId}/decision/. Fonte: poa/serializers/poa.py:212-227 (POAV3Serializer, que estende POAV2Serializer em poa/serializers/poa.py:173-209).

Verificação de telefone

Retornado para cada tentativa de verificação de telefone. Aparece como phone_verifications[] em GET /v3/session/{sessionId}/decision/ tanto para sessões KYC quanto KYB. Fonte: phone/serializers/phone.py:251-266 (PhoneV3Serializer, estende PhoneV2Serializer em phone/serializers/phone.py:103-248).

Verificação de e-mail

Retornado para cada tentativa de verificação de e-mail. Aparece como email_verifications[] em GET /v3/session/{sessionId}/decision/ tanto para sessões KYC quanto KYB. Fonte: email_verification/serializers/email.py:149-164 (EmailV3Serializer, estende EmailV2Serializer em email_verification/serializers/email.py:38-146).

Validação de banco de dados

Retornado por consulta a banco de dados executada sobre os dados enviados pelo usuário. Aparece como database_validations[] em GET /v3/session/{sessionId}/decision/. Fonte: database_validation/serializers/database_validation.py:21-142 (DatabaseValidationV3Serializer, estende DatabaseValidationV2Serializer).

Resposta do questionário

Retornada para cada envio de questionário. Aparece como questionnaire_responses[] em GET /v3/session/{sessionId}/decision/ tanto para sessões de KYC quanto de KYB. Fonte: questionnaires/serializers/questionnaire.py:591-597 (QuestionnaireResponseV3Serializer, que estende QuestionnaireResponseSerializer em questionnaires/serializers/questionnaire.py:520-588).

Assinatura eletrônica

Retornada para cada signatário de uma etapa de Assinatura eletrônica. Aparece como signatures[] em GET /v3/session/{sessionId}/decision/ tanto para sessões de KYC quanto de KYB, somente quando o fluxo de verificação tem a etapa. Diferentemente dos outros objetos de relatório, seu status indica a fase da assinatura e o resultado está em verdict, e os itens de warnings[] são { code, node_id } em vez de objetos de aviso. O relatório de assinatura eletrônica tem um exemplo completo e todos os campos aninhados.

Estimativa de idade

Retornado pela API de estimativa de idade independente (POST /v3/age-estimation/). A resposta traz um subconjunto da estrutura de Liveness check sob um envelope age_estimation: status, method, score, age_estimation e warnings, mais um bloco user_image de detecção facial exclusivo do modo independente. Ela não inclui reference_image, video_url, matches, face_quality ou face_luminance. Em sessões com fluxo de verificação (workflow) não há um array separado: a idade estimada aparece como liveness_checks[].age_estimation em GET /v3/session/{sessionId}/decision/. Fonte: apis/serializers/age_estimation.py:50-55 (AgeEstimationResponseSerializer), envelope montado em apis/views/age_estimation.py:138-174.

Autenticação biométrica

A autenticação biométrica executa o mesmo pipeline de Prova de vida + Correspondência facial usado no KYC padrão, mas configurado para comparar o rosto capturado com a imagem de referência de um usuário existente, em vez de um retrato de documento recém-extraído por OCR. Não há serializador dedicado: GET /v3/session/{sessionId}/decision/ retorna os objetos padrão de verificação de prova de vida e correspondência facial em liveness_checks[] e face_matches[]. O fluxo da sessão é configurado com workflow_type = "biometric_authentication" (WorkflowTypeChoices, common/config/choices.py:636).

Registro KYB

Retornado para cada empresa confirmada pelo registro em um fluxo KYB. Aparece como registry_checks[] em GET /v3/session/{sessionId}/decision/ para sessões de empresas. Origem: kyb/serializers/kyb.py:939-964 (RegistryCheckV3Serializer).

Objeto de empresa

Origem: kyb/serializers/kyb.py:220-321 (KYBCompanyResponseSerializer).

Documento KYB

Retornado por nó que coleta documentos de apoio KYB. Aparece como document_verifications[] em GET /v3/session/{sessionId}/decision/ para sessões de empresas: uma entrada por node_id, com items[] listando cada documento enviado. Fonte: kyb/serializers/kyb.py:1053-1068 (DocumentVerificationV3Serializer); cada item segue kyb/serializers/kyb.py:811-851 (KYBDocumentResponseSerializer).

Objeto de item de documento KYB

Pessoa-chave KYB

Retornado por nó de pessoas-chave em um fluxo KYB. Aparece como key_people_checks[] em GET /v3/session/{sessionId}/decision/ para sessões de empresas. Fonte: kyb/serializers/kyb.py:967-1050 (KeyPeopleCheckV3Serializer).

Campos no nível da decisão

Essas chaves ficam ao lado dos arrays de recursos em GET /v3/session/{sessionId}/decision/ e dentro do decision de um webhook. Consulte Recuperar sessão para saber como lê-los.

Consentimento biométrico

Toda decisão e todo webhook de sessão da Verificação de usuários trazem um único objeto biometric_consent (não um array): se a sessão exigiu consentimento biométrico explícito, por quê, e a evidência da resposta. Ele é null quando a sessão nunca foi avaliada, por exemplo em um fluxo sem captura facial. Origem: BiometricConsentDecisionSerializer (sessions/serializers/biometric_consent.py). Quando a etapa aparece e o que significa cada caso está explicado em Consentimento biométrico. Campos sem valor registrado são null, nunca uma string vazia. Uma sessão em Illinois atendida por um SDK nativo anterior à 4.10.0, que capturou a selfie sem a etapa:
Uma pessoa usando uma VPN com saída fora dos EUA, que concordou no fluxo hospedado:

Referência do enum de status

Dois conjuntos de valores relacionados compartilham o nome de campo status. Todos os objetos de relatório por recurso nesta página usam o enum de recurso; o status de nível superior da sessão principal usa o enum de sessão, mais amplo.

Status no nível do recurso

Usados pelo campo status de todos os objetos de relatório. Fonte: common/config/choices.py:343-348 (FeatureStatusChoices). A verificação de telefone, de e-mail e de identidade também pode retornar Expired quando a etapa correspondente atinge o tempo limite (PhoneStatusChoices em common/config/choices.py:377-382, EmailStatusChoices em common/config/choices.py:434-439).

Status no nível da sessão

Usados pelo status de nível superior da sessão principal. Fonte: common/config/choices.py:106-117 (StatusChoices).
Os valores finais de sessão são Approved, Declined, In Review, Expired, Kyc Expired e Abandoned. Uma sessão pode chegar à decisão geral enquanto um recurso individual permanece em In Review.
Última modificação em 14 de novembro de 2026