Formas de integrar: API, SDKs e links sem código
Não precisas de escrever código para começar a verificar pessoas com a Didit - usa um link sem código, ou recorre a um SDK ou à API quando quiseres automação.
Três caminhos. Os links sem código não precisam de qualquer backend. A API com um redirecionamento é a integração padrão. Os SDKs colocam o fluxo dentro da tua própria aplicação - e são o único caminho que suporta NFC. Seja qual for a tua escolha, obtém os resultados através de webhooks.
Não precisas de um programador para lançar a verificação de identidade com a Didit. Existe uma opção sem código que demora minutos, além de opções de API e SDK para quando quiseres automatizar dentro do teu próprio produto.
#Posso usar a Didit sem programar?
Sim. Depois de criares um fluxo de trabalho na consola, podes gerar uma sessão de verificação de duas formas, sem qualquer código:
- O primeiro passo emite a chave de API com que o teu backend se autentica.
- O segundo passo escolhe o fluxo de trabalho que cada sessão vai correr.
- O terceiro passo regista onde os resultados são enviados, e faz um envio de teste.
- O quarto passo é o código: copia o guia rápido para a tua stack.
- Link de verificação (pontual)
A partir da página Fluxos de trabalho, cria uma sessão diretamente na consola. Obténs um URL único e um código QR para essa pessoa - envia-o por e-mail, SMS, ou qualquer canal, ou pede-lhe que digitalize o código presencialmente.
- Link reutilizável (Unilink)
Cada fluxo de trabalho tem também um link reutilizável que inicia uma sessão nova a cada visita. Coloca-o atrás de um botão no teu site, imprime-o como código QR para um quiosque ou balcão, ou partilha-o com afiliados. Consulta links reutilizáveis.
Ambos ignoram por completo a API e o teu backend - a escolha certa para MVPs, revisão manual, verificação presencial, ou para começar antes de teres construído algo à medida.
#Quando quiseres automação
Se precisares que o resultado atualize os teus próprios sistemas automaticamente - e não apenas apareça na consola - vais querer a API ou um SDK:
| Queres... | Usa |
|---|---|
| Redirecionar os utilizadores da tua aplicação para uma página de verificação alojada | Uma única chamada de API para criar uma sessão, e depois redirecionar para o URL devolvido |
| Incorporar a verificação dentro da tua aplicação web | O SDK de JavaScript ou o iframe in-context |
| Verificar dentro de uma aplicação nativa 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 |
| Integrar numa ferramenta de automação | A API a partir do Zapier, n8n, ou qualquer ferramenta que consiga fazer um pedido HTTP e receber um webhook |
| Receber os resultados enviados para o teu backend assim que estiverem prontos | Webhooks |
| Executar comprovações individuais por conta própria (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 |
#Enviar o link tu mesmo
Se criares uma sessão através da API, a Didit devolve o URL de verificação - e enviá-lo passa a ser contigo. Enviá-lo a partir do teu próprio produto, com a tua própria mensagem e imagem de marca, costuma ser inclusive a melhor experiência: a pessoa já confia em ti, e uma mensagem de um remetente desconhecido tem um custo de conversão.
Se precisares que seja a Didit a enviar o e-mail à pessoa, passa os dados de contacto ao criar a sessão. Confirma o que é suportado na tua configuração em vez de presumir, e nota que o idioma do e-mail é um campo separado do idioma do fluxo. Consulta definir o idioma da verificação.
#Escolher entre alojado, incorporado e nativo
| Redirecionamento alojado | Incorporado (SDK web / iframe) | SDK nativo | |
|---|---|---|---|
| Código necessário | Mínimo | Moderado | Máximo |
| O utilizador sai da tua aplicação | Sim | Não | Não |
| Leitura de chip NFC | Não | Não | Sim |
| Melhor comportamento de câmara | Bom | Bom | Melhor |
| O domínio personalizado remove a Didit do URL | Sim | n/a | n/a |
Se o NFC for importante para ti, essa linha decide a questão: o chip não pode ser lido a partir de uma página de navegador. Consulta verificação de chip NFC.
Vale a pena confirmar com o teu contacto na Didit quais opções incorporadas estão disponíveis no teu plano antes de planeares um projeto à volta de uma delas.
#APIs autónomas vs sessões de fluxo de trabalho
Uma sessão de fluxo de trabalho executa as comprovações em conjunto, produz uma decisão agregada e recorre às franquias gratuitas por funcionalidade nas quatro funcionalidades do plano gratuito. Uma chamada de API autónoma executa uma comprovação sobre os dados que fornecerdes, devolve apenas esse resultado, e é faturada por chamada, sem franquia gratuita.
As chamadas autónomas são a ferramenta certa para processamento em lote, para uma interface de captura que construíste tu mesmo, ou para uma comprovação que queres correr fora de um fluxo de integração. São a ferramenta errada se querias o plano gratuito.
#Testar antes de ires para produção
Cria uma aplicação separada em modo sandbox para testes - cada aplicação tem a sua própria chave de API e fluxos de trabalho, por isso o tráfego de teste nunca toca em dados reais, e as sessões em sandbox não custam nada e permitem-te forçar qualquer resultado. Consulta testar em sandbox.
#Próximos passos
- Configura primeiro um fluxo de trabalho, se ainda não o fizeste: criar um fluxo de verificação
- Recebe os resultados assim que estiverem prontos: obter resultados de verificação com webhooks
- Onde encontrar a tua chave de API: gerir as tuas chaves de API
- Quando algo devolve um erro: erros da API e o que significam