> ## 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 backend: Python, Node.js, Go, Java, PHP, Ruby, .NET > Chame as APIs da Didit no seu backend com um SDK oficial e tipado. 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/api-reference/overview.md) com pedidos e respostas tipados, verifica os webhooks que a Didit lhe envia e valida os tokens do [Didit Authentication](https://docs.didit.me/pt/authentication/overview.md). Nenhuma versão 1.0.1 tem ainda os dois endpoints do Google Wallet: [iniciar uma verificação do Google Wallet](https://docs.didit.me/pt/api-reference/digital-id-wallets/google-wallet.md) e [enviar uma resposta de carteira](https://docs.didit.me/pt/standalone-apis/digital-id-wallet-response.md). Os SDK de Python, Node.js, Java, PHP, Ruby e .NET têm todos os outros endpoints de servidor. O SDK Go 1.0.1 também não tem mais nove, a maioria deles endpoints da Travel Rule: veja [Endpoints que ainda não estão no SDK Go](https://docs.didit.me/pt/integration/server-sdks/go.md#endpoints-que-ainda-não-estão-no-sdk-de-go). Use-os sempre que o seu código tenha uma chave de API da Didit: na criação de sessões de verificação, na leitura de decisões, na chamada às APIs independentes, na gestão de utilizadores, empresas, fluxos e casos, na triagem de transações e carteiras e na Travel Rule. No navegador ou numa aplicação móvel, use em vez disso os SDK [web](https://docs.didit.me/pt/integration/web-sdks/overview.md) e [nativos](https://docs.didit.me/pt/integration/native-sdks/overview.md): apresentam o fluxo de verificação ao seu utilizador 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/api-reference/overview.md), incluindo as páginas do serviço [Validação de base de dados](https://docs.didit.me/pt/standalone-apis/database-validation.md), mostram um exemplo de código para cada SDK de servidor ao lado do pedido cURL. Um exemplo só é mostrado quando a versão mais recente do SDK tem o endpoint e todos os campos que o exemplo envia: um endpoint ou campo acrescentado à API recebe os seus exemplos na versão seguinte de cada SDK. Nenhuma versão 1.0.1 tem os 16 campos de pedido da Validação de base de dados acrescentados depois de o SDK ter sido gerado, 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 | Runtime mínimo | | - | - | - | - | | [Python](https://docs.didit.me/pt/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/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 edge com `fetch` | | [Go](https://docs.didit.me/pt/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/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/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/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/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, pelo que um cliente criado sem opções fica pronto a utilizar. Os ambientes de execução edge não têm ambiente de processo: nesses casos, passe a chave de API ao cliente Node.js como opção. | Variável | Utilizada para | | - | - | | `DIDIT_API_KEY` | Todas as chamadas com chave de API. Crie a chave na consola, em [Chaves de API](https://docs.didit.me/pt/console/api-keys.md). | | `DIDIT_ORGANIZATION_ID`, `DIDIT_APPLICATION_ID` | Operações em `/v3/organization/{organization_id}/application/{application_id}/` (casos, redes, relatórios regulamentares, modelos de relatório e algumas ferramentas de utilizadores e empresas). O SDK preenche os dois IDs de caminho a partir do cliente, pelo que nunca os passa em cada chamada. Sem eles, estas chamadas falham antes de ser enviado qualquer pedido. | | `DIDIT_LOG=debug` | Regista o método, o caminho, o estado, a duração e o ID do pedido de cada pedido. Os corpos e os cabeçalhos nunca são registados. | Tudo o que pode definir através do ambiente também pode ser passado ao cliente, juntamente com o URL base, o tempo limite, as novas tentativas, os cabeçalhos predefinidos e o seu próprio cliente HTTP. Crie um cliente por processo e partilhe-o: ele mantém um pool de ligações e é seguro para utilizar a partir de várias threads ou tarefas. Os métodos `account` ([registo programático](https://docs.didit.me/pt/integration/programmatic-registration.md): registar, iniciar sessão, organizações e aplicações) chamam `https://apx.didit.me/auth/v2` e nunca enviam a sua chave de API. Inicie sessão com `account.login` e, depois, passe o token de acesso devolvido ao cliente como o seu token de conta. ## O que faz cada SDK * **Recursos e métodos.** As chamadas seguem os recursos da API: `client..(...)`, por exemplo `sessions.create`, `sessions.retrieve_decision` ou `transactions.create`, com a capitalização própria de cada linguagem. Os IDs de caminho são argumentos posicionais; o corpo e os parâmetros de consulta são um único conjunto de campos com nome. Python, Node.js, PHP e Ruby usam os nomes de campo da própria API (`workflow_id`); Go, Java e .NET usam a capitalização da sua linguagem (`WorkflowID`, `workflowId`, `WorkflowId`). * **Listas.** Os métodos de listagem percorrem todos os resultados por si (`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 o `total_count`, o `next_url` e o `previous_url` de uma página correspondem ao `count`, ao `next` e ao `previous` da API. * **Ficheiros.** Os envios (imagens de documentos, selfies, comprovativos de morada, importações) aceitam um caminho, bytes ou um stream. Os downloads (PDF de sessões, relatórios) devolvem bytes ou um stream, nunca JSON analisado. * **Compatibilidade futura.** Um campo de resposta ou um valor de enumeração que a versão do SDK ainda não conhece é mantido e legível, nunca um erro, para que uma adição à API não quebre uma integração em produção. * **Webhooks.** `webhooks.verify` verifica os cabeçalhos `X-Signature-V2` e `X-Signature` e a marca temporal de uma entrega com o seu segredo de webhook, e devolve um evento tipado. Aceita uma lista de segredos enquanto faz a rotação de um deles. Veja [Webhooks](https://docs.didit.me/pt/integration/webhooks.md) para o esquema de assinatura. * **Autenticação.** Um auxiliar `Authentication` verifica os tokens de acesso e de ID que o seu emissor de Authentication assina, e chama os seus endpoints de token, de sessão e de autenticação step-up. Nunca utiliza a sua chave de API. ## Erros, novas tentativas e tempos limite | Erro | Quando | | - | - | | `APIConnectionError`, `APITimeoutError` | Não chegou nenhuma resposta | | `APIStatusError` | Qualquer outra resposta que não seja 2xx, com o estado, o corpo analisado, os cabeçalhos e o ID do pedido | | `BadRequestError` 400, `AuthenticationError` 401, `PermissionDeniedError` 403, `NotFoundError` 404, `ConflictError` 409, `UnprocessableEntityError` 422, `RateLimitError` 429, `InternalServerError` 5xx | Subclasses de `APIStatusError` | | `WebhookVerificationError` | A verificação de uma entrega de webhook falhou; o seu `reason` indica o motivo | | `ConfigurationError` | Falta a chave de API, o token da conta, o ID da organização ou o ID da aplicação | Todos os erros derivam de `DiditError`. Em Go, todos os erros implementam a interface `didit.Error` e são tipos de ponteiro, como `*didit.NotFoundError`. Java, PHP e .NET usam o sufixo habitual `Exception` e escrevem `API` como `Api`: `DiditException`, `ApiStatusException`, `NotFoundException`. Os SDK voltam a tentar um pedido que falhou até 2 vezes, com recuo exponencial a partir de 0,5 segundos (jitter total, com no máximo 8 segundos) e respeitando o `Retry-After`. Os pedidos `GET`, `HEAD`, `PUT` e `DELETE` são repetidos em caso de erros de ligação, tempos limite, 408, 429 e 5xx. Os pedidos `POST` e `PATCH` são repetidos apenas em caso de 429 ou quando a ligação falhou antes de o pedido ser enviado, para que uma nova tentativa nunca crie uma segunda sessão ou transação. O tempo limite predefinido é de 60 segundos. Cada resposta expõe também o estado HTTP bruto, os cabeçalhos e o ID do pedido. Consulte [Limites de pedidos](https://docs.didit.me/pt/integration/rate-limiting.md) para os limites por trás do 429. ## Versionamento e suporte * Os SDK seguem o versionamento semântico, com uma regra para alterações da API. Uma alteração que espelha a API da Didit é uma versão menor, mesmo que possa quebrar código tipado (um campo cujo tipo mudou, um campo que passou a poder ser nulo, ou um endpoint, campo ou valor de enumeração removido). A API já se comporta dessa forma para todos os clientes, por isso uma versão anterior do SDK não é mais segura. As notas de versão listam essas alterações em "Alterações à API que podem quebrar código tipado". * Uma versão principal destina-se apenas a uma alteração ao design do próprio SDK: um método ou recurso renomeado ou removido enquanto a API o mantém, uma alteração à configuração do cliente, aos erros, às novas tentativas, à paginação ou ao comportamento da verificação de webhooks, ou a remoção do suporte a uma versão de runtime. Quando um endpoint sai da API ou um método é renomeado, o método antigo mantém-se durante pelo menos mais uma versão menor, marcado como obsoleto, para que o seu código continue a compilar enquanto migra para o novo. Cada linguagem mantém o seu próprio número de versão: Node.js, PHP e Ruby estão na 2.x e as restantes na 1.x, porque essas três lançaram uma alteração da API como versão principal antes de esta regra ser aplicada. * Os SDK são gerados a partir do contrato da API publicado ([`openapi-25.json`](https://docs.didit.me/openapi-25.json) e [`openapi-auth.json`](https://docs.didit.me/openapi-auth.json)), e os seus métodos de [Didit Authentication](https://docs.didit.me/pt/authentication/overview.md) são verificados em relação a [`openapi-authentication.json`](https://docs.didit.me/openapi-authentication.json). Os SDK verificam os três todos os dias, pelo que um novo endpoint ou campo chega numa versão regular dos sete SDK. * Cada SDK suporta a versão mínima de runtime indicada na tabela e todas as versões mais recentes. Os seus testes são executados na versão mínima e em cada versão mais recente, ou em cada versão de suporte prolongado (LTS) no caso de Node.js e Java. * O `CHANGELOG.md` de cada repositório lista as alterações de cada versão. * Comunique um problema de segurança de forma privada através dos avisos de segurança do repositório do SDK ou enviando-o para [support@didit.me](mailto:support@didit.me). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.