Pular para o conteúdo principal
Alguns padrões que mostram em que o MCP da Didit se destaca. Formule as solicitações em linguagem simples: o agente escolhe as ferramentas. Todas as ferramentas citadas abaixo existem na referência de ferramentas.

Prompts rápidos

Operações e monitoramento (entre aplicações)
  • “Mostre as últimas 5 sessões em revisão de todas as minhas aplicações.” → didit_session_search com status: "In Review", limit: 5
  • “Quantas pessoas tentaram a verificação de telefone, mas abandonaram nos últimos 15 dias?” → didit_analytics com last_n_days: 15 (uma única chamada; lê o funil do recurso)
  • “Encontre o cliente com vendor_data user_8842 e me diga a qual aplicação está associado e qual é o status.” → didit_vendor_user_search
  • “Qual é o meu saldo de créditos e a taxa de conversão deste mês?” → didit_org_get_balance + didit_analytics
Configuração
  • “Crie um fluxo de verificação (workflow) de KYC com leitura de documento + prova de vida e me dê um link de verificação.” → didit_workflow_create → didit_session_create
  • “Crie um fluxo de verificação de identidade que aceite apenas passaportes, seguido de uma prova de vida por selfie.” → didit_workflow_create: basta dizer documents_allowed: ["PASSPORT"]; o MCP expande isso para aceitar somente passaportes em todos os países (consulte Avançado → configurações de recursos).
  • “Novo fluxo: ler um passaporte; se o documento for recusado, recusar a sessão; se a profissão informada for ≈ ‘Software Engineer’ (≥60%), fazer uma prova de vida; caso contrário, pedir um comprovante de endereço em espanhol; depois, decidir automaticamente.” → didit_workflow_get_field_definitions → didit_workflow_validate_graph → didit_workflow_set_graph
  • “No fluxo 26d33c04…, depois da verificação de identidade: se for recusada, recusar a sessão; se a profissão for ≥80% semelhante a ‘Software Engineer’, adicionar uma etapa de Document-AI para comprovante de fundos; depois, continuar.” → didit_workflow_search → didit_workflow_get_graph → didit_workflow_edit_graph (operações pequenas, salvas como um rascunho revisável)
  • “Em quais países posso oferecer login com BankID ou MitID em vez da leitura de um documento?” → didit_workflow_get_id_verification_methods_catalog
  • “Registre um destino do webhook para atualizações de status em https://myapp.com/webhooks/didit.” → didit_webhook_create
Conformidade
  • “Faça a triagem AML desta carteira e adicione-a à lista de bloqueio se houver correspondência.” → didit_transaction_screen_wallet → didit_blocklist_add
  • “Abra um caso para a sessão … e atribua-o a mim.” → didit_case_create → didit_case_manage
  • “A Acme Ltd é uma empresa registrada no Reino Unido? Quem são os acionistas?” → didit_verify_kyb_search → didit_verify_kyb_select

1. Colocar a verificação no ar

Você: “Configure a verificação de identidade da Didit na minha aplicação com leitura de documento e prova de vida, e me dê um link para eu testar.” Agente: Primeiro vou criar o fluxo. (chama didit_workflow_create com workflow_label: "Standard KYC", features: [{ "feature": "OCR" }, { "feature": "LIVENESS" }]): publiquei “Standard KYC”, workflow_id = 6f2c…. Agora, uma sessão para testar. (chama didit_session_create com workflow_id: "6f2c…", vendor_data: "test-user-1"): aqui está o seu link: https://verify.didit.me/session/…. Abra-o no celular para percorrer o fluxo. Em produção, o seu backend cria as sessões com a API REST:
Esse x-api-key é a chave de API REST da sua aplicação, usada pelo seu backend; ela é independente da forma como você entrou neste MCP, que usa Log in with Didit. Quer que eu registre também o destino do webhook? Você: “Sim, o meu endpoint é https://myapp.com/webhooks/didit.” Agente: (chama didit_webhook_create com label: "Production", url: "https://myapp.com/webhooks/didit", webhook_version: "v3", subscribed_events: ["status.updated"]): pronto. O segredo de assinatura vem ocultado na resposta que recebo, então copie-o em Webhooks no console e guarde-o como DIDIT_WEBHOOK_SECRET. Verifique o cabeçalho X-Signature-V2 de cada entrega antes de confiar nela.

2. KYB: verificar uma empresa no registro de empresas

Você: “A Acme Trading Ltd é uma empresa real do Reino Unido? Tenho o número de registro 12345678.” Agente: (chama didit_verify_kyb_search com country_code: "GB", name: "Acme Trading Ltd", registration_number: "12345678"): um candidato: ACME TRADING LTD, constituída em 2019, status ativo, sede registrada em Manchester. Quer o registro completo, com administradores e acionistas? Você: “Sim, e me diga quem são os beneficiários finais.” Agente: (chama didit_verify_kyb_select com o kyb_response_id do candidato): registro completo obtido: dois diretores e uma pessoa com controle significativo que detém 75%+ das ações e dos direitos de voto. O registro inclui o histórico de arquivamentos e o endereço registrado. Esta foi uma consulta cobrada ao registro de empresas (duas chamadas que consomem créditos). Se quiser que isso aconteça automaticamente para todo cliente empresarial, posso adicionar KYB_REGISTRY a um fluxo de KYB com didit_workflow_create; didit_workflow_get_kyb_registry_catalog nos informa quais níveis de dados o registro do Reino Unido vende.

3. Processe a fila de revisão

Você: “O que está aguardando minha revisão e qual é o problema de cada uma?” Agente: (chama didit_session_search com status: "In Review", limit: 10): quatro sessões em duas aplicações estão em revisão. Vou ler cada decisão. (chama didit_session_get_decision para cada session_id) Você: “Aprove a1f3: conferi a selfie e é a mesma pessoa. Recuse b7c2, documento expirado.” Agente: (chama didit_session_update_status com session_id: "a1f3…", new_status: "Approved" e depois com session_id: "b7c2…", new_status: "Declined", comment: "Expired document"): as duas foram atualizadas. (chama didit_session_add_review em a1f3… com a nota “Manual selfie review: same person”): nota de revisão adicionada para que o registro de auditoria mostre por que a pontuação foi ignorada. Os dois casos de AML e de comprovante de endereço continuam abertos; é só pedir, e eu abro um caso para o resultado PEP com didit_case_create.

4. Teste uma regra de transação retrospectivamente antes de ativá-la

Você: “Quero sinalizar quem fizer mais de 3 transferências acima de $1,000 em uma hora. Quantos alertas isso geraria?” Agente: (chama didit_transaction_rule_backtest com conditions sobre amount > 1000, uma aggregation de contagem ≥ 3 em uma janela de 1 hora, period_days: 90): Nos últimos 90 dias, essa regra teria disparado em 14 transações de 6 titulares; 2 desses titulares já estão sinalizados. Quer que eu a crie no modo TEST, para que ela registre as correspondências sem executar nenhuma ação? Você: “Sim, modo TEST.” Agente: (chama didit_transaction_rule_create com title: "Velocity: 3+ transfers over $1,000 per hour", category: "aml_ctf", mode: "TEST", as mesmas conditions e aggregation e uma lista de actions que sinaliza o titular): regra criada. Acompanhe-a com didit_transaction_rule_get depois de alguns dias; quando estiver satisfeito, didit_transaction_rule_update muda o mode para ACTIVE. didit_transaction_rule_library_list também traz as regras de velocidade predefinidas da Didit, caso você prefira instalar uma delas.

Os resultados da sessão são assíncronos

didit_session_create retorna um session_id, um session_token e uma url hospedada, mas a verificação ainda não aconteceu. O usuário abre a url e conclui o fluxo. A decisão final chega por meio de:
  1. Um webhook status.updated (recomendado), ou
  2. didit_session_get_decision (polling, como alternativa).
Os dois têm o mesmo formato: sempre arrays no plural, com um node_id por entrada:
Nunca leia as chaves V2 no singular (id_verification, liveness): elas só são enviadas quando um destino está explicitamente configurado com webhook_version: "V2". Consulte Modelos de dados para a referência de campos de cada recurso e Avançado → Webhooks para as regras de verificação e de novas tentativas.

Combine-o com a integração de um único prompt

O MCP é ótimo para operar a Didit. Para que um agente escreva uma integração completa (rota de backend + SDK de frontend + handler de webhook + esquema de banco de dados), entregue a ele o Prompt de integração: ele percorre as sete etapas e chama ferramentas MCP para criar o fluxo de verificação (workflow), a sessão e o webhook em tempo real.

Referência de ferramentas

Tudo o que o agente pode chamar.

Avançado e solução de problemas

Funções, comportamento entre aplicações, webhooks, auto-hospedagem.
Última modificação em 1 de novembro de 2026