> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # SDKs de servidor: Python, Node, Go, Java, PHP, Ruby, .NET > Use as APIs de servidor da Didit no seu backend com SDKs oficiais e tipados: instalação, configuração, erros, novas tentativas, versões e suporte. 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](https://docs.didit.me/pt-br/api-reference/overview.md) com requisições e respostas tipadas, verifica os webhooks que a Didit envia a você e valida os tokens do [Didit Authentication](https://docs.didit.me/pt-br/authentication/overview.md). Nenhuma versão 1.0.1 inclui ainda os dois endpoints do Google Wallet: [iniciar uma verificação do Google Wallet](https://docs.didit.me/pt-br/api-reference/digital-id-wallets/google-wallet.md) e [enviar uma resposta da carteira](https://docs.didit.me/pt-br/standalone-apis/digital-id-wallet-response.md). 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](https://docs.didit.me/pt-br/integration/server-sdks/go.md#endpoints-que-ainda-não-estão-no-sdk-para-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](https://docs.didit.me/pt-br/integration/web-sdks/overview.md) e [nativos](https://docs.didit.me/pt-br/integration/native-sdks/overview.md): 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](https://docs.didit.me/pt-br/api-reference/overview.md), incluindo as páginas dos serviços de [Validação de banco de dados](https://docs.didit.me/pt-br/standalone-apis/database-validation.md), 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 ```bash Python theme={null} pip install didit-sdk ``` ```bash Node.js theme={null} npm install @didit-protocol/sdk-node ``` ```bash Go theme={null} go get github.com/didit-protocol/sdk-go ``` ```kotlin Java theme={null} implementation("me.didit:didit-java:1.0.1") ``` ```bash PHP theme={null} composer require didit-protocol/sdk-php guzzlehttp/guzzle ``` ```bash Ruby theme={null} gem install didit-sdk ``` ```bash .NET theme={null} dotnet add package Didit ``` | Linguagem | Pacote | Código-fonte | Ambiente de execução mínimo | | - | - | - | - | | [Python](https://docs.didit.me/pt-br/integration/server-sdks/python.md) | [PyPI `didit-sdk`](https://pypi.org/project/didit-sdk/) | [sdk-python](https://github.com/didit-protocol/sdk-python) | Python 3.10 | | [Node.js e TypeScript](https://docs.didit.me/pt-br/integration/server-sdks/node.md) | [npm `@didit-protocol/sdk-node`](https://www.npmjs.com/package/@didit-protocol/sdk-node) | [sdk-node](https://github.com/didit-protocol/sdk-node) | Node.js 18, Bun, Deno, ambientes de execução de edge com `fetch` | | [Go](https://docs.didit.me/pt-br/integration/server-sdks/go.md) | [Módulo Go `github.com/didit-protocol/sdk-go`](https://pkg.go.dev/github.com/didit-protocol/sdk-go) | [sdk-go](https://github.com/didit-protocol/sdk-go) | Go 1.22 | | [Java e Kotlin](https://docs.didit.me/pt-br/integration/server-sdks/java.md) | [Maven Central `me.didit:didit-java`](https://central.sonatype.com/artifact/me.didit/didit-java) | [sdk-java](https://github.com/didit-protocol/sdk-java) | Java 11 | | [PHP](https://docs.didit.me/pt-br/integration/server-sdks/php.md) | [Packagist `didit-protocol/sdk-php`](https://packagist.org/packages/didit-protocol/sdk-php) | [sdk-php](https://github.com/didit-protocol/sdk-php) | PHP 8.1 | | [Ruby](https://docs.didit.me/pt-br/integration/server-sdks/ruby.md) | [RubyGems `didit-sdk`](https://rubygems.org/gems/didit-sdk) | [sdk-ruby](https://github.com/didit-protocol/sdk-ruby) | Ruby 3.1 | | [C# e .NET](https://docs.didit.me/pt-br/integration/server-sdks/dotnet.md) | [NuGet `Didit`](https://www.nuget.org/packages/Didit) | [sdk-dotnet](https://github.com/didit-protocol/sdk-dotnet) | .NET 8 ou .NET Standard 2.0 | ## 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. | Variável | Usada para | | - | - | | `DIDIT_API_KEY` | Todas as chamadas com chave de API. Crie a chave no console em [Chaves de API](https://docs.didit.me/pt-br/console/api-keys.md). | | `DIDIT_ORGANIZATION_ID`, `DIDIT_APPLICATION_ID` | Operações em `/v3/organization/{organization_id}/application/{application_id}/` (casos, redes, relatórios regulatórios, modelos de relatório e algumas ferramentas de usuários e empresas). O SDK preenche os dois ids do caminho a partir do cliente, então você nunca precisa passá-los em cada chamada. Sem eles, essas chamadas falham antes de qualquer requisição ser enviada. | | `DIDIT_LOG=debug` | Registra em log o método, o caminho, o status, a duração e o ID de cada requisição. Corpos e cabeçalhos nunca são registrados. | 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](https://docs.didit.me/pt-br/integration/programmatic-registration.md): 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..(...)`, 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](https://docs.didit.me/pt-br/integration/webhooks.md) 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 | Erro | Quando | | - | - | | `APIConnectionError`, `APITimeoutError` | Nenhuma resposta chegou | | `APIStatusError` | Qualquer outra resposta fora da faixa 2xx, com o status, o corpo analisado, os cabeçalhos e o ID da requisição | | `BadRequestError` 400, `AuthenticationError` 401, `PermissionDeniedError` 403, `NotFoundError` 404, `ConflictError` 409, `UnprocessableEntityError` 422, `RateLimitError` 429, `InternalServerError` 5xx | Subclasses de `APIStatusError` | | `WebhookVerificationError` | Uma entrega de webhook falhou na verificação; o `reason` informa o motivo | | `ConfigurationError` | Falta a chave de API, o token da conta, o ID da organização ou o ID da aplicação | 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](https://docs.didit.me/pt-br/integration/rate-limiting.md) 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`](https://docs.didit.me/openapi-25.json) e [`openapi-auth.json`](https://docs.didit.me/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](mailto:support@didit.me). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.