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 abrangem cada objeto de relatório por funcionalidade. O texto dos títulos H3 é intencionalmente estável, para que outros documentos possam criar ligações diretas para eles.

Verificação de identidade

É devolvido para cada documento de KYC/identidade submetido pelo utilizador. 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 não documental. Mudam apenas os campos específicos do método: tudo o que uma leitura do documento preenche é, em vez disso, preenchido a partir do registo oficial ou dos atributos da carteira, e os campos que não se aplicam ficam a null.

Verificação NFC

Devolvido para cada leitura de chip realizada com um documento de identidade: um chip de passaporte eletrónico ICAO 9303 ou de eID, ou um cartão My Number do Japão lido através do JPKI (chip_protocol: "jpki"). Aparece como nfc_verifications[] em GET /v3/session/{sessionId}/decision/ (um por registo KYC principal). 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, que estende LivenessV2Serializer em face/serializers/face.py:216-298).
Uma sessão PASSIVE devolve este campo quando a captura guardou uma gravação, e null quando a sessão não guardou gravação; o exemplo acima é uma sessão que não guardou nenhuma.

Correspondência facial

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

Pesquisa facial

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

Objeto de correspondência de pesquisa facial

Triagem AML

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

Análise de IP

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

Verificação de localização

Devolvido para 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 estão no Relatório de verificação de localização.

Comprovativo de morada

Devolvido por cada documento de morada 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

Devolvido por cada tentativa de verificação de telefone. Aparece como phone_verifications[] em GET /v3/session/{sessionId}/decision/ para sessões KYC e 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/ para sessões KYC e 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 consulta à base de dados executada sobre 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 ao questionário

Devolvida por cada submissão de questionário. Aparece como questionnaire_responses[] em GET /v3/session/{sessionId}/decision/, tanto para sessões KYC como KYB. Origem: questionnaires/serializers/questionnaire.py:591-597 (QuestionnaireResponseV3Serializer, que 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/, tanto para sessões KYC como KYB, apenas quando o fluxo tem o passo. Ao contrário dos restantes 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 } 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

Devolvido pela API autónoma de Estimativa de idade (POST /v3/age-estimation/). A resposta contém um subconjunto da forma de Liveness check, dentro de um envelope age_estimation com status, method, score, age_estimation e warnings, além de um bloco user_image de deteção facial exclusivo da API autónoma; 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/. 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 na 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 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).

Registo KYB

Devolvido por cada empresa confirmada pelo registo num 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 da empresa

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

Documento KYB

Devolvido por cada nó que recolhe documentos de apoio KYB. Surge como document_verifications[] em GET /v3/session/{sessionId}/decision/ para sessões de empresas: uma entrada por node_id, com 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. Surge como key_people_checks[] em GET /v3/session/{sessionId}/decision/ para sessões de empresas. Origem: 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 14 de novembro de 2026