Saltar para o conteúdo principal

Visão geral

Cada relatório por funcionalidade segue a forma do serializador V3 definida em service-didit-verification. O mesmo objeto aparece em três sítios, pelo que o esquema que vê aqui é a fonte única de verdade para todos eles:
  • GET /v3/session/{sessionId}/decision/: cada funcionalidade é devolvida 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[] (ver Métodos de verificação bancária), e os equivalentes KYB registry_checks[], document_verifications[], key_people_checks[]).
  • Payloads de webhook (status.updated, data.updated): a mesma forma dentro do envelope decision.
  • APIs autónomas: as respostas de objeto único (Pesquisa facial, Estimativa de idade, Autenticação biométrica) reutilizam o mesmo conjunto de campos.
A V3 introduziu fluxos multi-instância: cada objeto de funcionalidade contém um node_id que associa o relatório ao nó do grafo do fluxo que o produziu. Os endpoints V2 (no singular kyc, face, aml, etc.) continuam compatíveis com versões anteriores, mas devolvem apenas a primeira instância.

Campos comuns

Cada objeto de relatório expõe o seguinte: Os campos de conteúdo multimédia (portrait_image, front_image, document_file, …) são URLs pré-assinados com um período de validade limitado. Transfira-os rapidamente em vez de guardar o URL. Os exemplos mostram-nos como https://<media-host>/....

Objeto de aviso

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

Objetos de relatório

As restantes secções abordam cada objeto de relatório por funcionalidade. O texto do título H3 é intencionalmente estável para que outros documentos possam ligar-se diretamente a ele.

Verificação de identidade

Devolvido para cada documento KYC/ID que o utilizador submete. Aparece como id_verifications[] em GET /v3/session/{sessionId}/decision/ e dentro do campo kyc das respostas V2. Origem: 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 uma leitura de documento preenche passa a ser preenchido a partir do registo da fonte ou dos atributos da carteira, e as chaves que não se aplicam ficam null.

Verificação NFC

Devolvido para cada leitura do chip de um documento de identidade: um chip ICAO 9303 de ePassport ou eID, ou uma leitura do Japan My Number Card através do JPKI (chip_protocol: "jpki"). Aparece como nfc_verifications[] em GET /v3/session/{sessionId}/decision/ (um por registo 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

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

Correspondência facial

Devolvido por cada comparação facial (normalmente o rosto da prova de vida do utilizador contra o retrato do documento). Aparece como face_matches[] em GET /v3/session/{sessionId}/decision/. Origem: face/serializers/face.py:367-389 (FaceMatchV3Serializer, estende FaceMatchV2Serializer em face/serializers/face.py:323-364).

Pesquisa facial

Devolvida pela API de Pesquisa facial autónoma (POST /v3/face-search/). A Pesquisa facial nunca aparece como um array no plural em /v3/session/{sessionId}/decision/. Quando é guardado com save_api_request=true, a sessão surge aí como uma entrada FACE_SEARCH em features[], mais um item em liveness_checks[] que contém as matches guardadas. Fontes: apis/serializers/face_search.py:8-79 (FaceSearchResponseSerializer, que envolve FaceSearchDetailsSerializer); os dicionários de correspondência são construídos em face/utils/utils.py:869-884. Resposta de nível superior: Objeto face_search:

Objeto de correspondência de Pesquisa facial

Triagem AML

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

Análise de IP

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

Verificação de localização

Devolvido por cada passo de Verificação de localização. Aparece como geolocation_checks[] em GET /v3/session/{sessionId}/decision/: um item por passo, correspondente à sua tentativa aceite. geolocation_attempts[] lista todas as tentativas de todos os passos, da mais antiga para a mais recente. Ambos são null num fluxo sem o passo. Origem: GeolocationDecisionSerializer. Todos os campos e exemplos constam do relatório de verificação de localização.

Comprovativo de morada

Devolvido por cada documento de morada submetido. Aparece como poa_verifications[] em GET /v3/session/{sessionId}/decision/. Origem: poa/serializers/poa.py:212-227 (POAV3Serializer, estende POAV2Serializer em poa/serializers/poa.py:173-209).

Verificação de telefone

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

Verificação de e-mail

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

Validação de base de dados

Devolvido por cada pesquisa na base de dados feita com os dados submetidos pelo utilizador. Aparece como database_validations[] em GET /v3/session/{sessionId}/decision/. Origem: database_validation/serializers/database_validation.py:21-142 (DatabaseValidationV3Serializer, estende DatabaseValidationV2Serializer).

Resposta do questionário

Devolvida por cada submissão de questionário. Aparece como questionnaire_responses[] em GET /v3/session/{sessionId}/decision/ para sessões KYC e KYB. Origem: questionnaires/serializers/questionnaire.py:591-597 (QuestionnaireResponseV3Serializer, estende QuestionnaireResponseSerializer em questionnaires/serializers/questionnaire.py:520-588).

Assinatura eletrónica

Devolvida por cada signatário de um passo de Assinatura eletrónica. Aparece como signatures[] em GET /v3/session/{sessionId}/decision/ para sessões KYC e KYB, apenas quando o fluxo tem o passo. Ao contrário dos outros objetos de relatório, o seu status é a fase de assinatura e o resultado está em verdict, e os itens de warnings[] são { code, node_id } e não objetos de aviso. O relatório de assinatura eletrónica tem um exemplo completo e todos os campos aninhados.

Estimativa de idade

Devolvido pela API autónoma de Estimativa de idade (POST /v3/age-estimation/). A resposta inclui um subconjunto da estrutura de Liveness check, dentro de um envelope age_estimation: status, method, score, age_estimation, warnings, mais um bloco autónomo user_image de deteção facial. Não inclui reference_image, video_url, matches, face_quality nem face_luminance. Em sessões de fluxo não existe um array separado: a idade estimada aparece como liveness_checks[].age_estimation em GET /v3/session/{sessionId}/decision/. Origem: 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 utilizador existente, em vez de um retrato do documento recém-extraído por OCR. Não existe um serializador dedicado: GET /v3/session/{sessionId}/decision/ devolve 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 está configurado com workflow_type = "biometric_authentication" (WorkflowTypeChoices, common/config/choices.py:636).

Registo KYB

Devolvido por cada empresa confirmada pelo registo num fluxo de verificação 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 da empresa

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

Documento KYB

Devolvido por cada nó que recolhe documentos de apoio KYB. Aparece como document_verifications[] em GET /v3/session/{sessionId}/decision/ para sessões de empresas, com uma entrada por node_id, e items[] a listar cada documento carregado. Origem: 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

Devolvido por cada nó de pessoas-chave num 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 ao nível da decisão

Estas chaves ficam junto às matrizes de funcionalidades em GET /v3/session/{sessionId}/decision/ e dentro de decision num webhook. Consulte Obter sessão para saber como os ler.

Consentimento biométrico

Cada decisão de Verificação de utilizadores e cada webhook de sessão inclui um único objeto biometric_consent (não um array): se a sessão exigiu consentimento biométrico explícito, o motivo e a prova da resposta. É null quando a sessão nunca foi avaliada, por exemplo num fluxo sem captura facial. Origem: BiometricConsentDecisionSerializer (sessions/serializers/biometric_consent.py). Quando o passo aparece e o que significa cada caso é explicado em Consentimento biométrico. Os campos sem valor registado são null, nunca uma string vazia. Uma sessão em Illinois processada por um SDK nativo anterior a 4.10.0, que captou a selfie sem o passo:
Uma pessoa numa VPN com saída fora dos EUA, que concordou no fluxo alojado:

Referência dos estados

Dois conjuntos de valores relacionados partilham o nome de campo status. Todos os objetos de relatório por funcionalidade desta página usam o enum de nível de funcionalidade. O status de nível superior da sessão principal usa o enum de sessão, mais abrangente.

Estados ao nível da funcionalidade

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

Estados ao nível da sessão

Usados pelo status de nível superior da sessão principal. Origem: common/config/choices.py:106-117 (StatusChoices).
Os valores terminais da sessão são Approved, Declined, In Review, Expired, Kyc Expired e Abandoned. Uma sessão pode atingir a sua decisão global enquanto uma funcionalidade individual permanece In Review.
Última modificação em 7 de novembro de 2026