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 abordam cada objeto de relatório por recurso. O texto dos títulos H3 é intencionalmente estável para que outros documentos possam criar links diretos para eles.

Verificação de identidade

Retornado para cada documento de KYC/identidade que um usuário envia. 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 que não é de documento. Apenas as chaves específicas do método mudam: tudo o que uma leitura de documento preencheria passa a ser preenchido a partir do registro consultado ou dos atributos da carteira, e as chaves que não se aplicam ficam null.

Verificação NFC

Retornado para cada leitura de chip de um documento de identidade: um chip de ePassport ou eID ICAO 9303, ou um My Number Card japonês 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, que estende NFCV2Serializer em kyc/serializers/epassport.py:83-118).

Verificação de prova de vida

Retornado por sessão de prova de vida. Aparece como liveness_checks[] em GET /v3/session/{sessionId}/decision/. Fonte: face/serializers/face.py:301-320 (LivenessV3Serializer, que estende LivenessV2Serializer em face/serializers/face.py:216-298).

Correspondência facial

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

Busca facial

Retornado pela API autônoma de Busca facial (POST /v3/face-search/). A Busca facial nunca aparece como array no plural em /v3/session/{sessionId}/decision/: quando persistida com save_api_request=true, a sessão aparece ali como uma entrada FACE_SEARCH em features[], além de um item liveness_checks[] com as matches armazenadas. Fontes: apis/serializers/face_search.py:8-79 (FaceSearchResponseSerializer encapsulando FaceSearchDetailsSerializer); dicionários de correspondência construídos em face/utils/utils.py:869-884. Resposta de nível superior: Objeto face_search:

Objeto de correspondência da busca facial

Análise AML

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

Análise de IP

Retornado para cada localização de rede capturada. Aparece como ip_analyses[] em GET /v3/session/{sessionId}/decision/ tanto para sessões de KYC quanto de KYB. Fonte: 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, com a tentativa aceita. geolocation_attempts[] lista todas as tentativas de todas as etapas, da mais antiga para a mais recente. Ambos são null em um fluxo sem essa etapa. Fonte: 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 endereço enviado. Aparece como poa_verifications[] em GET /v3/session/{sessionId}/decision/. Origem: 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/ para sessões KYC e KYB. Fonte: phone/serializers/phone.py:251-266 (PhoneV3Serializer, que 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/ para sessões KYC e KYB. Fonte: email_verification/serializers/email.py:149-164 (EmailV3Serializer, que estende EmailV2Serializer em email_verification/serializers/email.py:38-146).

Validação de banco de dados

Retornado para cada 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, que estende DatabaseValidationV2Serializer).

Resposta de questionário

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

Assinatura eletrônica

Retornado para cada signatário de uma etapa de Assinatura eletrônica. Aparece como signatures[] em GET /v3/session/{sessionId}/decision/ tanto em sessões KYC quanto KYB, somente quando o fluxo tem essa etapa. Diferentemente dos outros objetos de relatório, o status dele é o estágio da assinatura e o resultado fica 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 traz um exemplo completo e todos os campos aninhados.

Estimativa de idade

Retornado pela API autônoma de Estimativa de idade (POST /v3/age-estimation/). A resposta traz um subconjunto da estrutura de Liveness check dentro de um envelope age_estimation (status, method, score, age_estimation, warnings), além de um bloco de detecção facial user_image exclusivo da API autônoma; ela não inclui reference_image, video_url, matches, face_quality nem face_luminance. Em sessões de 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), com o 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á um serializer dedicado: GET /v3/session/{sessionId}/decision/ retorna os objetos padrão Liveness check e Face match 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 no registro em um fluxo de verificação (workflow) de KYB. Aparece como registry_checks[] em GET /v3/session/{sessionId}/decision/ para sessões de empresas. Fonte: kyb/serializers/kyb.py:939-964 (RegistryCheckV3Serializer).

Objeto de empresa

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

Documento KYB

Retornado para cada nó que coleta documentos de suporte de KYB. Aparece como document_verifications[] em GET /v3/session/{sessionId}/decision/ para sessões de empresas, com uma entrada por node_id e 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 para cada 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 1 de novembro de 2026