> ## 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.

# Server SDKs: Python, Node.js, Go, Java, PHP, Ruby, .NET

> Call the Didit server APIs from your backend with an official, typed SDK. Install matrix, configuration, errors, retries, versioning and support policy.

The server SDKs are the official Didit libraries for your backend. Each one calls the server endpoints of the [API reference](https://docs.didit.me/api-reference/overview.md) with typed requests and responses, verifies the webhooks Didit sends you, and checks the tokens of [Didit Authentication](https://docs.didit.me/authentication/overview.md). No 1.0.1 release has the two Google Wallet endpoints yet: [start a Google Wallet verification](https://docs.didit.me/api-reference/digital-id-wallets/google-wallet.md) and [submit a wallet response](https://docs.didit.me/standalone-apis/digital-id-wallet-response.md). The Python, Node.js, Java, PHP, Ruby and .NET SDKs have every other server endpoint. Go 1.0.1 also lacks nine more, most of them Travel Rule endpoints: see [Endpoints not in the Go SDK yet](https://docs.didit.me/integration/server-sdks/go.md#endpoints-not-in-the-go-sdk-yet).

Use them wherever your code holds a Didit API key: creating verification sessions, reading decisions, calling the standalone APIs, managing users, businesses, workflows and cases, screening transactions and wallets, and the Travel Rule. In the browser or a mobile app, use the [web](https://docs.didit.me/integration/web-sdks/overview.md) and [native](https://docs.didit.me/integration/native-sdks/overview.md) SDKs instead: they present the verification flow to your user and never hold your API key.

Server endpoint pages of the [API reference](https://docs.didit.me/api-reference/overview.md), including the [Database Validation](https://docs.didit.me/standalone-apis/database-validation.md) service pages, show a code sample for each server SDK next to the cURL request. A sample is shown once the SDK's latest release has the endpoint and every field the sample sends: an endpoint or field added to the API gets its samples with the next release of each SDK. No 1.0.1 release has the 16 Database Validation request fields added after it was generated, such as `vin` or `bank_account_number`, so the service pages that send them show cURL only.

## Install

```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
```

| Language | Package | Source | Minimum runtime |
| - | - | - | - |
| [Python](https://docs.didit.me/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 and TypeScript](https://docs.didit.me/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, edge runtimes with `fetch` |
| [Go](https://docs.didit.me/integration/server-sdks/go.md) | [Go module `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 and Kotlin](https://docs.didit.me/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/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/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# and .NET](https://docs.didit.me/integration/server-sdks/dotnet.md) | [NuGet `Didit`](https://www.nuget.org/packages/Didit) | [sdk-dotnet](https://github.com/didit-protocol/sdk-dotnet) | .NET 8 or .NET Standard 2.0 |

## Configure

Every SDK reads the same environment variables, so a client created with no options is ready to use. Edge runtimes have no process environment: there, pass the API key to the Node.js client as an option.

| Variable | Used for |
| - | - |
| `DIDIT_API_KEY` | Every API key call. Create the key in the console under [API keys](https://docs.didit.me/console/api-keys.md). |
| `DIDIT_ORGANIZATION_ID`, `DIDIT_APPLICATION_ID` | Operations under `/v3/organization/{organization_id}/application/{application_id}/` (cases, networks, regulatory reports, report templates and some user and business tools). The SDK fills both path ids from the client, so you never pass them per call. Without them those calls fail before any request is sent. |
| `DIDIT_LOG=debug` | Logs the method, path, status, duration and request id of every request. Bodies and headers are never logged. |

Anything you can set through the environment you can also pass to the client, along with the base URL, timeout, retries, default headers and your own HTTP client. Create one client per process and share it: it keeps a connection pool and is safe to use from several threads or tasks.

The `account` methods ([programmatic registration](https://docs.didit.me/integration/programmatic-registration.md): register, sign in, organizations and applications) call `https://apx.didit.me/auth/v2` and never send your API key. Sign in with `account.login`, then pass the returned access token to the client as its account token.

## What every SDK does

* **Resources and methods.** Calls follow the API's resources: `client.<resource>.<method>(...)`, for example `sessions.create`, `sessions.retrieve_decision` or `transactions.create`, in each language's own case. Path ids are positional arguments; the body and the query are one set of named fields. Python, Node.js, PHP and Ruby use the API's own field names (`workflow_id`); Go, Java and .NET use their language's case (`WorkflowID`, `workflowId`, `WorkflowId`).
* **Lists.** List methods page through every result for you (`limit` and `offset` underneath), and also expose each page with `count`, `next`, `previous` and `results`. In Ruby, `auto_paging_each` goes through every page, and a page's `total_count`, `next_url` and `previous_url` are the API's `count`, `next` and `previous`.
* **Files.** Uploads (document images, selfies, proof of address, imports) accept a path, bytes or a stream. Downloads (session PDFs, reports) return bytes or a stream, never parsed JSON.
* **Forward compatibility.** A response field or an enum value the SDK version does not know yet is kept and readable, never an error, so an API addition does not break a deployed integration.
* **Webhooks.** `webhooks.verify` checks the `X-Signature-V2` and `X-Signature` headers and the timestamp of a delivery with your webhook secret, and returns a typed event. It accepts a list of secrets while you rotate one. See [Webhooks](https://docs.didit.me/integration/webhooks.md) for the signature scheme.
* **Authentication.** An `Authentication` helper verifies the access and ID tokens your Authentication issuer signs, and calls its token, session and step-up endpoints. It never uses your API key.

## Errors, retries and timeouts

| Error | When |
| - | - |
| `APIConnectionError`, `APITimeoutError` | No response arrived |
| `APIStatusError` | Any other non-2xx response, with the status, the parsed body, the headers and the request id |
| `BadRequestError` 400, `AuthenticationError` 401, `PermissionDeniedError` 403, `NotFoundError` 404, `ConflictError` 409, `UnprocessableEntityError` 422, `RateLimitError` 429, `InternalServerError` 5xx | Subclasses of `APIStatusError` |
| `WebhookVerificationError` | A webhook delivery failed verification; its `reason` says why |
| `ConfigurationError` | A missing API key, account token, organization id or application id |

Every error derives from `DiditError`. In Go, every error implements the `didit.Error` interface and is a pointer type such as `*didit.NotFoundError`. Java, PHP and .NET name them with their usual `Exception` suffix and write `API` as `Api`: `DiditException`, `ApiStatusException`, `NotFoundException`.

The SDKs retry a failed request up to 2 times, with exponential backoff from 0.5 seconds (full jitter, at most 8 seconds) and honouring `Retry-After`. `GET`, `HEAD`, `PUT` and `DELETE` are retried on connection errors, timeouts, 408, 429 and 5xx. `POST` and `PATCH` are retried only on 429 or when the connection failed before the request was sent, so a retry never creates a second session or transaction. The default timeout is 60 seconds. Every response also exposes the raw HTTP status, headers and request id. See [Rate limiting](https://docs.didit.me/integration/rate-limiting.md) for the limits behind 429.

## Versioning and support

* The SDKs follow semantic versioning. When an endpoint leaves the API or its method is renamed, the old method stays for at least one more minor version, marked deprecated, so your code keeps building while you move to the new one.
* They are generated from the published API contract ([`openapi-25.json`](https://docs.didit.me/openapi-25.json) and [`openapi-auth.json`](https://docs.didit.me/openapi-auth.json)) and check it every day, so a new endpoint or field arrives in a regular release of all seven SDKs.
* Each SDK supports the minimum runtime in the table and every newer release. Its tests run on the minimum and on each newer release, or each long-term support release for Node.js and Java.
* Each repository's `CHANGELOG.md` lists the changes of every release.
* Report a security issue privately through the SDK repository's security advisories or to [support@didit.me](mailto:support@didit.me).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.