Saltar para o conteúdo principal
A few patterns that show what the Didit MCP is good at. Formule os pedidos em linguagem simples: o agente escolhe as ferramentas. Todas as ferramentas mencionadas abaixo existem na referência de ferramentas.

Pedidos rápidos

Operações e monitorização (entre aplicações)
  • “Mostre-me as últimas 5 sessões em análise em todas as minhas aplicações.” → didit_session_search com status: "In Review", limit: 5
  • “Quantas pessoas tentaram a verificação de telefone mas abandonaram o processo nos últimos 15 dias?” → didit_analytics com last_n_days: 15 (uma chamada; lê o funil de funcionalidades)
  • “Encontre o cliente com vendor_data user_8842 e diga-me em que aplicação está e qual é o estado.” → 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 KYC com leitura do documento de identidade + prova de vida e dê-me uma ligação de verificação.” → didit_workflow_create → didit_session_create
  • “Crie um fluxo de verificação de identidade que aceite apenas passaportes e, depois, uma prova de vida por selfie.” → didit_workflow_create. Basta indicar documents_allowed: ["PASSPORT"]; o MCP expande-o para apenas passaporte em todos os países (ver Avançado → configurações de funcionalidades).
  • “Novo fluxo: ler um passaporte; se o documento de identidade for recusado, recuse a sessão; se a profissão declarada for ≈ ‘Software Engineer’ (≥60%), execute uma prova de vida; caso contrário, peça comprovativo de morada em espanhol; depois, decida automaticamente.” → didit_workflow_get_field_definitions → didit_workflow_validate_graph → didit_workflow_set_graph
  • “No fluxo 26d33c04…, após a verificação de identidade: se for recusada, recuse a sessão; se a profissão for ≥80% semelhante a ‘Software Engineer’, adicione um passo de Document AI para comprovativo de fundos; depois, continue.” → didit_workflow_search → didit_workflow_get_graph → didit_workflow_edit_graph (pequenas operações, guardadas como rascunho revisível)
  • “Em que países posso oferecer início de sessão com BankID ou MitID em vez da leitura de um documento?” → didit_workflow_get_id_verification_methods_catalog
  • “Registe um destino de webhook para atualizações de estado 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 um resultado positivo.” → 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 registada no Reino Unido? Quem são os seus acionistas?” → didit_verify_kyb_search → didit_verify_kyb_select

1. Configurar a verificação

Você: “Configure a verificação de identidade da Didit para a minha aplicação com leitura do documento de identidade e prova de vida, e dê-me uma ligação que eu possa experimentar.” Agente: Vou criar primeiro o fluxo. (chama didit_workflow_create com workflow_label: "Standard KYC", features: [{ "feature": "OCR" }, { "feature": "LIVENESS" }]) — Publicado “Standard KYC”, workflow_id = 6f2c…. Agora uma sessão para o experimentar. (chama didit_session_create com workflow_id: "6f2c…", vendor_data: "test-user-1") — Aqui está a sua ligação: https://verify.didit.me/session/…. Abra-a no telemóvel para executar o fluxo. Em produção, o seu backend cria sessões com a REST API:
Esse x-api-key é a chave de API REST da sua aplicação para o seu backend; é diferente da forma como iniciou sessão neste MCP, que usa Log in with Didit. Quer que registe 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"]) — Feito. O segredo de assinatura vem ocultado na resposta, por isso copie-o de Webhooks na consola e guarde-o como DIDIT_WEBHOOK_SECRET. Verifique o cabeçalho X-Signature-V2 em cada entrega antes de confiar nela.

2. KYB: verificar uma empresa no registo

Você: “A Acme Trading Ltd é uma empresa real no Reino Unido? Tenho o número de registo 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, estado ativo, sede registada em Manchester. Quer o registo completo com administradores e acionistas? Você: “Sim, e diga-me quem são os beneficiários efetivos.” Agente: (chama didit_verify_kyb_select com o kyb_response_id do candidato) — Registo completo obtido: dois administradores e uma pessoa com controlo significativo, detentora de 75%+ das ações e dos direitos de voto. O registo inclui o histórico de documentos depositados e a sede registada. Esta consulta ao registo foi faturável (duas chamadas que consomem créditos). Se quiser que isto aconteça automaticamente para todos os clientes empresariais, posso adicionar KYB_REGISTRY a um fluxo KYB com didit_workflow_create; didit_workflow_get_kyb_registry_catalog indica-nos quais os níveis de dados que o registo do Reino Unido vende.

3. Processar a fila de revisão

Você: “O que está à espera da minha revisão e o que está errado em cada caso?” Agente: (chama didit_session_search com status: "In Review", limit: 10) Quatro sessões em duas aplicações estão em análise. A ler a decisão de cada uma. (chama didit_session_get_decision para cada session_id) Você: “Aprove a1f3: já vi 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") Ambas atualizadas. (chama didit_session_add_review para a1f3… com a nota “Revisão manual da selfie: mesma pessoa”) Nota de revisão adicionada para que o registo de auditoria mostre por que razão a pontuação foi substituída. Os dois casos de AML e de comprovativo de morada continuam abertos; diga-me e abro um caso para a correspondência PEP com didit_case_create.

4. Testar retroativamente uma regra de transação antes de entrar em produção

Você: “Quero sinalizar quem faça mais de 3 transferências acima de $1,000 numa hora. Quantos alertas ou falsos positivos geraria?” Agente: (chama didit_transaction_rule_backtest com conditions sobre amount > 1000, uma aggregation de contagem ≥ 3 numa janela de 1 hora, period_days: 90) Nos últimos 90 dias, esta regra teria disparado em 14 transações de 6 sujeitos; 2 desses sujeitos já estão sinalizados. Quer que a crie no modo TEST, para que registe 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 actions que sinaliza o sujeito) Criada. Acompanhe-a com didit_transaction_rule_get após alguns dias; quando estiver satisfeito, didit_transaction_rule_update muda mode para ACTIVE. didit_transaction_rule_library_list também tem as regras de velocidade predefinidas da Didit, caso prefira instalar uma.

Os resultados das sessões são assíncronos

didit_session_create devolve um session_id, um session_token e um url da página de verificação alojada, mas a verificação ainda não aconteceu. O utilizador abre o url e conclui o fluxo. A decisão final chega através de:
  1. Um webhook status.updated (recomendado), ou
  2. didit_session_get_decision (consulta periódica, como alternativa).
Ambos têm a mesma estrutura: sempre arrays no plural com um node_id por entrada:
Nunca leia as chaves V2 no singular (id_verification, liveness): só são enviadas quando um destino de webhook está explicitamente fixado a webhook_version: "V2". Consulte Modelos de dados para a referência de campos por funcionalidade 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 executar a Didit. Para que um agente escreva uma integração completa (rota de backend + SDK de frontend + processador de webhook + esquema da base de dados), forneça-lhe o Prompt de integração: ele percorre os sete passos e chama ferramentas MCP para criar o fluxo, a sessão e o webhook em tempo real.

Referência de ferramentas

Tudo o que o agente pode chamar.

Avançado e resolução de problemas

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