Saltar para o conteúdo principal
Use estes campos de config dentro de cada item do array features em POST /v3/workflows/ e PATCH /v3/workflows/{settings_uuid}/.
A API de fluxos v3 cria um fluxo linear baseado em nós a partir do array features ordenado. Envie as funcionalidades pela ordem exata de execução.
O motor que executa uma funcionalidade, o da própria Didit ou o de um fornecedor terceiro, não é um dos campos de configuração abaixo. É gerido através do Marketplace da consola, que define provider_key e fallback_to_native no objeto config da funcionalidade por si.

Regras de validação

  • OCR usa por defeito todos os países e tipos de documento suportados quando config.documents_allowed é omitido, null ou {}. Se enviar um objeto documents_allowed personalizado, este tem de conter pelo menos um país válido e um tipo de documento ativo. Cada configuração de documento pode definir sides como 1 para captura apenas da frente ou 2 para captura da frente e do verso.
  • QUESTIONNAIRE exige config.questionnaire_uuid.
  • KYB_DOCUMENTS exige config.kyb_required_document_groups.
  • SIGNATURE recusa signature_level: "qes" com qes_not_available até as assinaturas qualificadas estarem disponíveis, e recusa um novo passo com signature_level: "aes", devolvendo aes_not_available enquanto signature_availability.aes for false no fluxo. Os respetivos documentos têm de existir quando uma sessão é criada: com signature_documents_source definido como workflow, o passo precisa de documentos carregados na consola, e um passo sem documentos pode permanecer como rascunho, mas não pode entrar em produção; com session, cada pedido de criação tem de enviar sign.documents.
  • FACE_MATCH tem de vir depois de OCR em pedidos de fluxo simples.
  • NFC e DATABASE_VALIDATION exigem OCR quando aparecem no mesmo fluxo. AML precisa de um de OCR, KYB_REGISTRY ou DOCUMENT_AI antes de si; com apenas DOCUMENT_AI antes dele, o full_name a analisar tem de poder ser preenchido, seja a partir de um campo do Document AI anterior já identificado como full_name, que é mapeado automaticamente, seja a partir de uma entrada explícita config.aml_field_sources (ver AML).
  • As sub-funcionalidades KYB, como KYB_DOCUMENTS e KYB_KEY_PEOPLE, exigem KYB_REGISTRY anteriormente no fluxo.
  • Um fluxo é um fluxo de pessoa (KYC) ou um fluxo de empresa (KYB), nunca os dois. Um fluxo que use qualquer funcionalidade KYB (KYB_REGISTRY, KYB_DOCUMENTS, KYB_KEY_PEOPLE) só pode combiná-la com AML, DOCUMENT_AI, QUESTIONNAIRE, PHONE_VERIFICATION, EMAIL_VERIFICATION, IP_ANALYSIS e SIGNATURE. Não pode incluir funcionalidades exclusivas de pessoas, como OCR, LIVENESS, FACE_MATCH, NFC, PROOF_OF_ADDRESS, DATABASE_VALIDATION ou AGE_ESTIMATION, e um fluxo de pessoa não pode incluir funcionalidades KYB. Num fluxo de empresa, DOCUMENT_AI compara qualquer campo marcado com is_full_name com a empresa verificada, e não com uma pessoa. Para verificar as pessoas por detrás de uma empresa, crie um fluxo KYC separado e referencie-o no nó KYB_KEY_PEOPLE usando kyb_ubo_verification_workflow, kyb_officer_verification_workflow ou kyb_shareholder_verification_workflow.
  • Os campos de ação usam DECLINE, REVIEW ou NO_ACTION, salvo se o campo abaixo indicar que é restrito.
  • Os campos de pontuação e de limiar são números de 0 a 100, salvo se for indicado um intervalo mais restrito.

Regras de estado comuns

Todas as funcionalidades suportam um array opcional status_rules. Use-o para substituir o estado da funcionalidade quando uma condição sobre um campo se verifica.
Leia o exemplo acima como: kyc.extra_fields.profession tem correspondência difusa com Soft. Engineer com uma pontuação mínima de 80 → definir o estado da funcionalidade como Declined. Para a Verificação de identidade, indique valores extraídos de extra_fields, como kyc.extra_fields.profession, as datas de validade da classe da carta de condução, como kyc.extra_fields.dl_class_code_b_from e kyc.extra_fields.dl_class_code_b_to, ou os códigos de restrição ou informação por classe, como kyc.extra_fields.dl_class_code_b_notes (coluna 12 das cartas de condução do Reino Unido). Estes valores vêm do objeto extra_fields do resultado do OCR; não fazem parte de expected_details.
Os campos dl_class_code_*_from e dl_class_code_*_to contêm sempre uma data ISO válida ou estão ausentes de extra_fields. A Didit nunca devolve texto OCR ilegível num campo de data. Se a célula da tabela de classes não puder ser lida, o campo é omitido em vez de ser enviado como string bruta, por isso use o operador is_empty para encaminhar datas de classe ilegíveis em vez de assumir que o campo está sempre presente.
Para campos de data, use value_type: "relative_date" com um objeto de valor da forma { "direction": "past" | "future", "amount": number, "unit": "days" | "months" | "years" }. Por exemplo, operator: "less_than" com { "direction": "past", "amount": 3, "unit": "years" } corresponde a datas com mais de três anos relativamente à data de hoje.

Comparar com um passo específico

Um fluxo em grafo pode executar a mesma funcionalidade mais do que uma vez, por exemplo três passos de Verificação de identidade. Com value_type: "field", acrescente @<node_id> ao valor para o ler de um passo específico. O nó referenciado tem de ser um passo de funcionalidade que seja sempre executado antes do passo da própria regra, em todos os caminhos que lá cheguem, ou o próprio passo da regra. Um valor sem o sufixo é lido a partir do passo da própria regra.
Leia esta regra, definida no terceiro passo de Verificação de identidade, como: o kyc.full_name deste passo tem correspondência difusa com o nome completo lido pelo passo ocr_1, com uma pontuação mínima de 80 → definir o estado da funcionalidade como Declined. Na consola, o seletor de variáveis lista cada passo elegível pelo seu número no ecrã e guarda o sufixo por si.

OCR / Verificação de identidade

Valor da funcionalidade: OCR.
A prova de vida do documento é configurada com os seis limiares document_liveness_* acima, e não com campos de ação por sinal. portrait_replacement_action, printed_copy_action e screen_capture_action são definições ao nível da conta e não são aceites numa configuração de funcionalidades de fluxo: a API remove as chaves de configuração desconhecidas ao guardar, por isso enviá-las aí não tem efeito. Cada sinal tem um limiar de recusa e um limiar de análise, numa escala de 0 a 100 em que uma pontuação mais alta significa que o documento tem mais probabilidade de ser genuíno.
Exemplo:

Métodos por país

methods é indexado pelo código de país ISO 3166-1 alfa-3. Cada país tem até três objetos de método; tudo o que omitir assume o predefinido.
wallet.on_failure pode ser fallback_to_document, decline ou retry. retry (apenas para a carteira, com a captura de documentos desativada para o país) permite que um utilizador cuja autenticação não terminou no passo da carteira tente novamente; a sessão nunca é recusada por esse motivo e mantém-se aberta até o utilizador concluir ou até expirar. As opções de id_lookup aceitam apenas fallback_to_document ou decline. Para manter os documentos fora do primeiro ecrã e oferecê-los apenas quando uma carteira ou uma consulta não resulta, defina document.fallback_only. O exemplo usa a Finlândia, onde a Finnish Trust Network é a primeira opção e a captura de documentos é a alternativa. A Finlândia também precisa de ter os seus tipos de documento ativados em documents_allowed (por exemplo, passaporte e cartão de identidade), para que a alternativa tenha documentos para oferecer.
As duas consultas acima estão available no catálogo atual, por isso esta configuração é guardada tal como está escrita. O bloco da carteira foi deixado de fora deste exemplo de propósito: a configuração de uma carteira só é guardada num país em que o catálogo a marca como available, e wallet.enabled: true em qualquer outro lugar é rejeitado e faz falhar a gravação inteira, incluindo a configuração das consultas. Quando o catálogo marcar uma carteira como available, acrescente-a a esse país:
Validação que a API aplica ao guardar:
  • Um código de país desconhecido, uma chave desconhecida dentro de um país ou uma chave desconhecida dentro de um método é rejeitado; nada é descartado silenciosamente.
  • Um país em que nenhum método esteja ativado é rejeitado: ninguém nesse país poderia ser verificado.
  • Uma carteira ou consulta só pode recorrer à captura de documentos quando a captura de documentos está ativada nesse país. fallback_to_document num país onde document.enabled é false é recusado em tempo de execução, porque não há para onde recorrer.
  • document.fallback_only: true é rejeitado com HTTP 400, a menos que document.enabled seja true e pelo menos uma carteira ou consulta de ID desse país recorra à captura de documentos.
A implementação atual no ambiente de staging aplica id_lookup.response_fields ao resultado da comparação, ao género opcional e aos retratos do registo retidos. Os campos de identidade obrigatórios continuam a fazer parte do registo de verificação. Isto não garante que todos os payloads intermédios do fornecedor fiquem excluídos do processamento. O lançamento em produção desta alteração não foi verificado; confirme o comportamento no ambiente de destino antes de depender da seleção de campos para requisitos de retenção.
Leia o catálogo de capacidades antes de escrever methods, através do separador Países da consola ou com a ferramenta MCP didit_workflow_get_id_verification_methods_catalog. O comportamento, a cobertura e a faturação estão em Métodos de verificação de identidade.

NFC / Passaporte eletrónico

Valor da funcionalidade: NFC.

Prova de vida

Valor da funcionalidade: LIVENESS.

Correspondência facial

Valor da funcionalidade: FACE_MATCH.

Estimativa de idade

Valor da funcionalidade: AGE_ESTIMATION.

Verificação de telefone

Valor da funcionalidade: PHONE_VERIFICATION. A Verificação de telefone fica desativada até que a organização conclua o primeiro carregamento de saldo.
O enriquecimento de inteligência do telefone é um complemento opcional. Quando phone_enrichment_enabled está true, cada verificação de telefone concluída é enriquecida com inteligência do telefone e faturada a $0.05 por pedido, além do custo padrão da verificação de telefone. As ações baseadas na pontuação só são aplicadas quando a pontuação de enriquecimento estiver disponível; as ações de índice de confiança, tipo de telefone e portabilidade são aplicadas assim que o enriquecimento é executado.A verificação da presença em redes sociais é um segundo complemento, separado. Quando phone_social_enabled está true, cada verificação de telefone concluída também indica em que plataformas online o número está registado (mensagens, redes sociais, comércio eletrónico e serviços profissionais) e é faturada a $0.05 por pedido. Pode ser ativada com ou sem phone_enrichment_enabled: os dois complementos têm preço e faturação independentes. Uma consulta que não encontra o número em nenhuma das plataformas que cobre é uma resposta válida e faturável, e aciona phone_no_social_presence_action. Utilize phone.social_profiles_registered (o número de plataformas em que o número está registado) para criar ramificações com base no resultado num grafo do fluxo.

Verificação de e-mail

Valor da funcionalidade: EMAIL_VERIFICATION.
O enriquecimento com informação de e-mail é um complemento opcional. Quando email_enrichment_enabled está true, cada verificação de e-mail concluída é enriquecida com informação de e-mail e é cobrada $0.05 por pedido, para além do custo habitual da verificação de e-mail. A ação baseada na pontuação entra em vigor assim que a pontuação de enriquecimento estiver disponível; as ações de violação de dados aplicam-se logo que o enriquecimento é executado.A verificação da presença online é um segundo complemento, separado. Quando email_social_enabled está true, cada verificação de e-mail concluída indica também em que plataformas online o endereço está registado (serviços de e-mail, redes sociais, serviços profissionais, de comércio eletrónico e de entretenimento) e é cobrada $0.05 por pedido. Pode ser ativada com ou sem email_enrichment_enabled: os dois complementos têm preço e faturação independentes. Uma consulta que não encontra o endereço em nenhuma das plataformas abrangidas é uma resposta válida e cobrável e aciona email_no_social_presence_action. Utilize email.social_profiles_registered (o número de plataformas em que o endereço está registado) para criar uma ramificação com base no resultado num grafo de fluxo.

Validação de base de dados

Valor da funcionalidade: DATABASE_VALIDATION. Exemplo:
database_validation_countries é o que faz este passo executar alguma coisa. Uma funcionalidade DATABASE_VALIDATION guardada sem este campo é aceite e depois não executa verificação alguma, por isso envie sempre pelo menos um país com pelo menos um ID de serviço.
Um ID de serviço que o passo não consegue executar é rejeitado com um 400 que o indica e explica o motivo, e nada é guardado. Isto inclui um ID que não está no catálogo, um ID que pertence a outro país, um serviço que ainda não está disponível e um serviço oferecido apenas através do POST /v3/database-validation/ autónomo. Um serviço cujas entradas nenhum passo anterior fornece é rejeitado da mesma forma, com a lista das entradas em falta. Um serviço que o fluxo guardado já inclui mas que já não consegue executar é removido quando voltar a guardar o fluxo. Por exemplo, este fluxo da Argentina lê o número de DNI e o género a partir da Verificação de identidade e verifica-os na RENAPER sem selfie:
Utilize arg_renaper em alternativa, após um passo LIVENESS, para também comparar a selfie com a fotografia que a RENAPER detém. Consulte a RENAPER para a pontuação de correspondência facial e o respetivo limiar.

Verificação bancária

Valor da funcionalidade: BANK_VERIFICATION. O utilizador verifica uma conta bancária, e o titular da conta indicado pelo banco é comparado com a identidade que um passo anterior do fluxo estabeleceu. O utilizador faz isto por um de dois métodos: início de sessão no banco (open_banking), em que inicia sessão no seu banco, ou verificação de conta (account_lookup), em que introduz os dados da conta e o banco confirma o nome associado. bank_method_order e o methods de cada país escolhem quais os métodos que um país oferece e qual vem primeiro; veja Métodos de verificação bancária. O passo produz evidências: uma pontuação do nome do titular, a comparação que a gerou e os códigos de motivo. As chaves bank_*_action transformam essas evidências num estado. Dois fatores determinam se o nó faz alguma coisa. bank_countries é uma lista de permissões, pelo que um mapa vazio não oferece nenhum banco e não executa nenhuma verificação. Além disso, o titular precisa de algo com que ser comparado: coloque antes do nó um passo OCR, DATABASE_VALIDATION ou QUESTIONNAIRE, envie expected_details na criação da sessão ou mapeie os campos por si com bank_field_sources. Sem nada disso, a propriedade só pode ser unknown, decisão que cabe a bank_reference_identity_missing_action.
A verificação bancária ainda está a ser implementada, por isso um nó BANK_VERIFICATION só é aceite numa conta onde tenha sido ativado. Em todas as outras, a gravação é rejeitada e o sistema indica-o. Também não é aqui que se configura a rota que executa o passo: isso é definido pelo par provider_key e fallback_to_native que o Marketplace da consola define para si.

Ligar uma conta

Quando o utilizador não consegue verificar

O utilizador pode sempre continuar sem banco, e o passo nunca o deixa bloqueado. Veja Quando a pessoa não consegue verificar o seu banco. O que a continuação significa para a sessão é bank_unsupported_action, bank_attempts_exhausted_action ou bank_skipped_action, consoante o motivo pelo qual o utilizador continuou, exceto se uma tentativa avaliada antes já tiver decidido o passo: consulte Ações do veredicto.

Comparar o titular

Verificação de conta

Estas chaves aplicam-se apenas à verificação de conta. A autenticação bancária mantém as suas correspondências aproximadas e o seu próprio bank_max_attempts.

Dados financeiros

bank_expected_currencies funciona apenas com o consentimento predefinido ownership. As outras três chaves leem dados financeiros reais, pelo que cada uma precisa do âmbito de consentimento correspondente em bank_scopes, e a gravação é recusada sem ele.

O que é armazenado

Ações de decisão

Cada chave aqui aceita DECLINE, REVIEW ou NO_ACTION, exceto quando estiver marcada como restrita, e recorre à predefinição abaixo quando a omite ou envia null. Nada que não seja prova positiva de propriedade é aprovado por predefinição, e só a prova demonstrável contra o utilizador leva à recusa.

Mais controlos

Estas chaves são opcionais. Cada chave de ação aceita DECLINE, REVIEW ou NO_ACTION. Exemplo de objeto config, para uma conta em que a Bank Verification está ativa e a rota escolhida cobre o país indicado:
bank_countries é o que faz este passo funcionar, e é validado contra a rota em que o nó é executado, não contra uma lista global. Um país em que essa rota não consegue estabelecer a propriedade da conta é recusado ao guardar e indicado no erro; por isso, leia o erro em vez de assumir que o país foi aceite e que será ignorado em tempo de execução.

AML

Valor da funcionalidade: AML. Para a triagem de pessoas no âmbito do KYC, use estes campos: Para a triagem de empresas no âmbito do KYB, use estes campos:

Triagem de uma entidade extraída por um passo de Document AI

Um passo AML lê normalmente quem é alvo da triagem a partir do passo OCR (uma pessoa) ou do passo KYB_REGISTRY (uma empresa). Um fluxo cujo único passo de extração é DOCUMENT_AI, ou seja, documentos não normalizados como um certificado fiscal ou uma escritura de constituição, não tem nenhum dos dois, por isso tem de indicar de onde vem cada entrada da triagem. Exemplo: triagem da empresa indicada numa acta constitutiva mexicana, sem nenhum documento de identificação no fluxo:
Sem um passo OCR nem um passo KYB_REGISTRY antes dele, um passo AML tem de conseguir preencher full_name, porque não há pesquisa no fornecedor sem um nome. Um fluxo que não mapeie nada, ou que mapeie uma chave do Document AI que nenhum passo anterior extrai, é rejeitado ao guardar, em vez de ser guardado e ficar a fazer triagem de nada. A precisão da AML depende diretamente de quantos identificadores forneceu: uma triagem apenas com nome é o que produz um volume elevado de falsos positivos.

Análise de dispositivo e IP

Valor da funcionalidade: IP_ANALYSIS. Exemplo:
Use recovered_device_action separadamente de duplicated_device_action quando quiser monitorizar dispositivos recuperados com elevada confiança antes de os recusar automaticamente. Isto é útil durante a implementação, porque as correspondências de dispositivos recuperados foram concebidas para detetar redes de fraude, mas ainda devem ser calibradas com o seu próprio tráfego.

Verificação de localização

Valor da funcionalidade: GEOLOCATION. Verifica onde a pessoa se encontra durante a verificação, a partir da posição do dispositivo ou da localização IP da ligação, face às áreas permitidas e bloqueadas, à localização IP e à morada do documento. Consulte Verificação de localização para saber como o passo se comporta e o respetivo relatório para os campos de decisão. Coloque-o depois de Verificação de identidade ou de Comprovativo de morada se quiser a distância até à morada de um documento, porque a distância só é medida quando existe uma morada registada. Com geolocation_position_source não definido, a distância até à localização IP exige um passo de Análise de dispositivo e IP no mesmo fluxo. Todas as chaves são opcionais: um passo com config vazio pede ao dispositivo uma posição com precisão de 250 m, com no máximo 120 segundos, dá à pessoa 3 tentativas e não aplica nenhuma regra de área. Cada conclusão tem a sua própria chave de ação. Uma chave de ação que não defina assume o predefinido do geolocation_preset escolhido ou, se não escolher nenhum, o predefinido por chave indicado abaixo. Uma localização incerta ou uma recusa de localização tem por predefinição REVIEW, nunca DECLINE, porque uma permissão negada ou um raio amplo não é prova de fraude. Uma ação que definir explicitamente prevalece sempre sobre o predefinido. Um desafio reproduzido (LOCATION_REPLAY_DETECTED) e uma falha na atestação do dispositivo (LOCATION_INTEGRITY_FAILED) recusam sempre e não têm chave de ação.

Formas das áreas

Cada item de geolocation_areas tem um id (de 1 a 64 caracteres de A-Z a-z 0-9 _ -, único na lista), uma label opcional (até 80 caracteres), um type de allowed ou blocked, e um kind que escolhe a forma. Uma lista tem no máximo 50 áreas e precisa de pelo menos uma área allowed enquanto is_geolocation_geofencing_enabled for true. geolocation_areas e geolocation_geofencing_by_country não podem ser enviados em conjunto, e geolocation_refusal_path: "end_session" exige que geolocation_permission_denied_action seja REVIEW ou DECLINE. A API recusa uma área que nunca poderia corresponder, como uma região de um país sem limites publicados, em vez de a guardar. Exemplo:

Comprovativo de morada

Valor da funcionalidade: PROOF_OF_ADDRESS.

Questionário

Valor da funcionalidade: QUESTIONNAIRE.

Registo de empresas (KYB)

Valor da funcionalidade: KYB_REGISTRY. kyb_registry_fields_config mapeia cada chave de campo configurável para {"enabled": bool, "required": bool}. enabled: false oculta o campo, enabled: true, required: false mostra-o como opcional, e enabled: true, required: true torna-o obrigatório na submissão. company_name, country_code e region são sempre mostrados e obrigatórios e não podem ser configurados. Quando o objeto é omitido, null ou {}, aplica-se a predefinição: apenas incorporation_date é obrigatório e todos os outros campos são opcionais.
Chaves dos campos configuráveis: registration_number, incorporation_date, legal_address, vat_number, alternative_names, tax_number, company_type, legal_entity_identifier, location_of_registration, nature_of_business, registered_capital_amount, registered_capital_currency, website, email, phone, control_scheme. Consulte campos configuráveis do formulário de registo para o comportamento junto do utilizador final e validação de IVA e de número de identificação fiscal para saber como vat_number e tax_number são verificados.

Documentos KYB

Valor da funcionalidade: KYB_DOCUMENTS.

Pessoas-chave KYB

Valor da funcionalidade: KYB_KEY_PEOPLE.

Document AI

Valor da funcionalidade: DOCUMENT_AI. Pede ao utilizador um ou mais documentos e extrai os campos que define, com um modelo de visão. Cada campo configurado torna-se um valor ramificável document_ai.<key>, e o resultado do passo é document_ai.status. Cada entrada em document_ai_documents é um documento: Cada entrada em fields de um documento é um campo: Exemplo:

Assinatura eletrónica

Valor da funcionalidade: SIGNATURE. Permite que a pessoa verificada, ou as pessoas-chave de uma empresa, assinem documentos, no nível Simple (predefinido) ou Advanced (AES). Coloque-a depois dos passos que verificam o signatário: Verificação de identidade e, para o código, Verificação de e-mail ou de telefone. Consulte Assinatura eletrónica. Os campos de um documento do fluxo são colocados no editor de modelos da consola. Para documentos de sessão, envie-os em sign.documents[].fields e envie os valores dos campos api.<key> em sign.field_values. Consulte Criar sessão. Exemplo, para documentos enviados com cada sessão:
Última modificação em 7 de novembro de 2026