Pular para o conteúdo principal
Os SDKs de servidor são as bibliotecas oficiais da Didit para o seu backend. Cada um chama os endpoints de servidor da referência da API com requisições e respostas tipadas, verifica os webhooks que a Didit envia a você e valida os tokens do Didit Authentication. Nenhuma versão 1.0.1 inclui ainda os dois endpoints do Google Wallet: iniciar uma verificação do Google Wallet e enviar uma resposta da carteira. Os SDKs de Python, Node.js, Java, PHP, Ruby e .NET têm todos os outros endpoints de servidor. O Go 1.0.1 também ainda não tem outros nove, a maioria deles endpoints de Travel Rule: veja Endpoints que ainda não estão no SDK de Go. Use-os em qualquer lugar onde o seu código guarde uma chave de API da Didit: para criar sessões de verificação, ler decisões, chamar as APIs avulsas, gerenciar usuários, empresas, fluxos de verificação (workflows) e casos, realizar a triagem de transações e carteiras, e cumprir a Travel Rule. No navegador ou em um app móvel, use os SDKs web e nativos: eles apresentam o fluxo de verificação ao seu usuário e nunca guardam a sua chave de API. As páginas de endpoints de servidor da referência da API, incluindo as páginas dos serviços de Validação de banco de dados, mostram um exemplo de código para cada SDK de servidor ao lado da requisição cURL. Um exemplo só aparece quando a versão mais recente do SDK já tem o endpoint e todos os campos que o exemplo envia: um endpoint ou campo adicionado à API ganha seus exemplos na próxima versão de cada SDK. Nenhuma versão 1.0.1 tem os 16 campos de requisição da Validação de banco de dados adicionados depois que ela foi gerada, como vin ou bank_account_number, por isso as páginas de serviço que os enviam mostram apenas cURL.

​
Instalação

​
Configuração

Todos os SDKs leem as mesmas variáveis de ambiente, então um cliente criado sem opções já está pronto para uso. Runtimes de edge não têm ambiente de processo: nesse caso, passe a chave de API ao cliente Node.js como opção. Tudo o que você pode definir pelo ambiente também pode ser passado ao cliente, junto com a URL base, o tempo limite, as novas tentativas, os cabeçalhos padrão e o seu próprio cliente HTTP. Crie um cliente por processo e compartilhe-o: ele mantém um pool de conexões e pode ser usado com segurança por várias threads ou tarefas. Os métodos account (cadastro programático: cadastro, login, organizações e aplicações) chamam https://apx.didit.me/auth/v2 e nunca enviam a sua chave de API. Faça login com account.login e depois passe o token de acesso retornado ao cliente como token da conta.

​
O que todo SDK faz

  • Recursos e métodos. As chamadas seguem os recursos da API: client.<resource>.<method>(...), por exemplo sessions.create, sessions.retrieve_decision ou transactions.create, no padrão de nomenclatura de cada linguagem. Os IDs do caminho são argumentos posicionais; o corpo e a query formam um único conjunto de campos nomeados. Python, Node.js, PHP e Ruby usam os próprios nomes de campo da API (workflow_id); Go, Java e .NET usam o padrão da sua linguagem (WorkflowID, workflowId, WorkflowId).
  • Listas. Os métodos de listagem percorrem todas as páginas de resultados para você (com limit e offset internamente) e também expõem cada página com count, next, previous e results. Em Ruby, auto_paging_each percorre todas as páginas, e total_count, next_url e previous_url de uma página correspondem a count, next e previous da API.
  • Arquivos. Os uploads (imagens de documentos, selfies, comprovante de endereço, importações) aceitam um caminho, bytes ou um stream. Os downloads (PDFs de sessão, relatórios) retornam bytes ou um stream, nunca JSON interpretado.
  • Compatibilidade futura. Um campo de resposta ou um valor de enum que a versão do SDK ainda não conhece é preservado e pode ser lido, nunca gera erro, de modo que uma adição à API não quebra uma integração já implantada.
  • Webhooks. webhooks.verify verifica os cabeçalhos X-Signature-V2 e X-Signature e o timestamp de uma entrega com o seu segredo de webhook, e retorna um evento tipado. Ele aceita uma lista de segredos enquanto você faz a rotação de um deles. Veja Webhooks para o esquema de assinatura.
  • Autenticação. Um helper Authentication verifica os tokens de acesso e de ID que o seu emissor do Authentication assina e chama os endpoints de token, sessão e step-up dele. Ele nunca usa a sua chave de API.

​
Erros, novas tentativas e tempos limite

Todo erro deriva de DiditError. Em Go, todo erro implementa a interface didit.Error e é um tipo ponteiro, como *didit.NotFoundError. Java, PHP e .NET os nomeiam com o sufixo habitual Exception e escrevem API como Api: DiditException, ApiStatusException, NotFoundException. Os SDKs tentam novamente uma requisição que falhou até 2 vezes, com backoff exponencial a partir de 0,5 segundo (full jitter, no máximo 8 segundos) e respeitando Retry-After. GET, HEAD, PUT e DELETE são repetidos em caso de erros de conexão, tempo limite excedido, 408, 429 e 5xx. POST e PATCH são repetidos apenas em caso de 429 ou quando a conexão falhou antes de a requisição ser enviada, de modo que uma nova tentativa nunca cria uma segunda sessão ou transação. O tempo limite padrão é de 60 segundos. Toda resposta também expõe o status HTTP bruto, os cabeçalhos e o ID da requisição. Consulte Limites de requisições para ver os limites por trás do 429.

​
Versionamento e suporte

  • Os SDKs seguem o versionamento semântico. Quando um endpoint sai da API ou o método dele é renomeado, o método antigo permanece por pelo menos mais uma versão secundária, marcado como obsoleto, para que seu código continue compilando enquanto você migra para o novo.
  • Eles são gerados a partir do contrato publicado da API (openapi-25.json e openapi-auth.json) e o verificam todos os dias, de modo que um novo endpoint ou campo é incluído em uma versão regular de todos os sete SDKs.
  • Cada SDK é compatível com o runtime mínimo indicado na tabela e com todas as versões posteriores. Os testes rodam no mínimo e em cada versão mais recente, ou em cada versão de suporte de longo prazo (LTS) no caso de Node.js e Java.
  • O CHANGELOG.md de cada repositório lista as mudanças de cada versão.
  • Relate um problema de segurança de forma privada por meio dos avisos de segurança (security advisories) do repositório do SDK ou pelo e-mail support@didit.me.
Última modificação em 1 de novembro de 2026