Formas de integrar: API, SDKs e links sem código
Você não precisa escrever código para começar a verificar pessoas com a Didit - use um link sem código, ou utilize um SDK ou a API quando quiser automação.
Três caminhos. Links sem código não precisam de nenhum backend. A API mais um redirecionamento é a integração padrão. SDKs colocam o fluxo dentro do seu próprio aplicativo - e são o único caminho que suporta NFC. Qualquer que seja a sua escolha, receba os resultados por webhooks.
Você não precisa de um desenvolvedor para lançar a verificação de identidade com a Didit. Há uma opção sem código que leva minutos, além de opções de API e SDK para quando você quiser automatizar tudo dentro do seu próprio produto.
#Posso usar a Didit sem programar?
Sim. Depois de criar um fluxo de trabalho no console, você pode gerar uma sessão de verificação de duas formas, sem escrever nenhum código:

- A etapa um emite a chave de API com a qual seu backend se autentica.
- A etapa dois escolhe o fluxo de trabalho que cada sessão vai executar.
- A etapa três registra para onde os resultados são enviados e dispara uma entrega de teste.
- A etapa quatro é o código: copie o guia rápido para a sua stack.
- Verification link (one-time)
Na página Workflows, crie uma sessão diretamente no console. Você recebe uma URL única e um QR code para aquela pessoa - envie por e-mail, SMS ou qualquer canal, ou peça que ela escaneie o código pessoalmente.
- Reusable link (Unilink)
Cada fluxo de trabalho também tem um link reutilizável que inicia uma nova sessão a cada visita. Coloque-o atrás de um botão no seu site, imprima-o como QR code para um quiosque ou uma filial, ou compartilhe com afiliados. Veja links reutilizáveis.
Ambos dispensam completamente a API e o seu backend - a escolha certa para MVPs, revisão manual, verificação presencial, ou para começar antes de você ter construído algo personalizado.
#Quando você quer automação
Se você precisa que o resultado atualize seus próprios sistemas automaticamente - não apenas apareça no console - vai querer usar a API ou um SDK:
| Você quer... | Use |
|---|---|
| Redirecionar usuários para uma página de verificação hospedada a partir do seu app | Uma única chamada de API para criar uma sessão e, em seguida, redirecionar para a URL retornada |
| Incorporar a verificação dentro do seu aplicativo web | O SDK JavaScript ou o iframe in-context |
| Verificar dentro de um app nativo iOS, Android, Flutter ou React Native | O SDK nativo correspondente - obrigatório para NFC |
| Adicionar verificação ao WordPress/WooCommerce ou Shopify | O plugin WordPress/WooCommerce ou Shopify - sem necessidade de código |
| Conectar a uma ferramenta de automação | A API a partir do Zapier, n8n, ou qualquer ferramenta que consiga fazer uma requisição HTTP e receber um webhook |
| Receber resultados enviados ao seu backend assim que estiverem prontos | Webhooks |
| Executar verificações individuais você mesmo (processamento em lote, interface de captura personalizada) | As APIs autônomas, chamadas diretamente em vez de através de uma sessão de fluxo de trabalho |
#Enviando o link você mesmo
Se você criar uma sessão pela API, a Didit retorna a URL de verificação - e entregá-la fica por sua conta. Enviar a partir do seu próprio produto, com seu próprio texto e sua própria marca, costuma ser a melhor experiência de qualquer forma: a pessoa já confia em você, e uma mensagem de um remetente desconhecido tem um custo de conversão.
Se você precisar que a Didit envie o e-mail para a pessoa, passe os dados de contato ao criar a sessão. Confirme o que é suportado para a sua configuração em vez de presumir, e observe que o idioma do e-mail é um campo separado do idioma do fluxo. Veja definindo o idioma da verificação.
#Escolhendo entre hospedado, incorporado e nativo
| Redirecionamento hospedado | Incorporado (SDK web / iframe) | SDK nativo | |
|---|---|---|---|
| Código necessário | Mínimo | Moderado | Máximo |
| Usuário sai do seu app | Sim | Não | Não |
| Leitura de chip NFC | Não | Não | Sim |
| Melhor comportamento de câmera | Bom | Bom | Melhor |
| Domínio personalizado remove a Didit da URL | Sim | n/a | n/a |
Se NFC é importante para você, essa linha decide a questão: o chip não pode ser lido a partir de uma página de navegador. Veja verificação de chip NFC.
Vale a pena confirmar com o seu contato na Didit quais opções incorporadas estão disponíveis no seu plano antes de planejar um projeto em torno de uma delas.
#APIs autônomas vs sessões de fluxo de trabalho
Uma sessão de fluxo de trabalho executa as verificações em conjunto, produz uma decisão agregada e utiliza as cotas gratuitas por recurso para os quatro recursos do nível gratuito. Uma chamada de API autônoma executa uma única verificação sobre dados que você fornece, retorna apenas esse resultado, e é cobrada por chamada, sem cota gratuita.
Chamadas autônomas são a ferramenta certa para processamento em lote, para uma interface de captura que você mesmo construiu, ou para uma verificação que você quer executar fora de um fluxo de onboarding. São a ferramenta errada se o que você queria era o nível gratuito.
#Testando antes de entrar em produção
Crie uma aplicação separada em modo sandbox para testes - cada aplicação tem sua própria chave de API e seus próprios fluxos de trabalho, então o tráfego de teste nunca toca os dados de produção, e as sessões de sandbox não custam nada, além de permitir forçar qualquer resultado. Veja testes no sandbox.
#Próximos passos
- Configure um fluxo de trabalho primeiro, caso ainda não tenha feito isso: criando um fluxo de trabalho de verificação
- Receba os resultados assim que estiverem prontos: recebendo resultados de verificação com webhooks
- Onde encontrar sua chave de API: gerenciando suas chaves de API
- Quando algo retorna um erro: erros da API e o que eles significam
