> ## 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. # SDK server: Python, Node.js, Go, Java, PHP, Ruby, .NET > Chiama le API server di Didit dal backend con un SDK ufficiale e tipizzato: installazione, configurazione, errori, retry e supporto. Gli SDK server sono le librerie ufficiali di Didit per il tuo backend. Ciascuno chiama gli endpoint server dell'[API reference](https://docs.didit.me/it/api-reference/overview.md) con richieste e risposte tipizzate, verifica i webhook che Didit ti invia e controlla i token di [Didit Authentication](https://docs.didit.me/it/authentication/overview.md). Nessuna release 1.0.1 include ancora i due endpoint di Google Wallet: [avviare una verifica Google Wallet](https://docs.didit.me/it/api-reference/digital-id-wallets/google-wallet.md) e [inviare una risposta del wallet](https://docs.didit.me/it/standalone-apis/digital-id-wallet-response.md). Gli SDK Python, Node.js, Java, PHP, Ruby e .NET includono tutti gli altri endpoint server. Go 1.0.1 manca anche di altri nove endpoint, per lo più endpoint Travel Rule: vedi [Endpoint non ancora presenti nell'SDK Go](https://docs.didit.me/it/integration/server-sdks/go.md#endpoint-non-ancora-presenti-nell’sdk-go). Usali ovunque il tuo codice contenga una chiave API Didit: creazione di sessioni di verifica, lettura delle decisioni, chiamate alle API autonome, gestione di utenti, aziende, workflow e casi, screening di transazioni e wallet, e Travel Rule. Nel browser o in un'app mobile, usa invece gli SDK [web](https://docs.didit.me/it/integration/web-sdks/overview.md) e [native](https://docs.didit.me/it/integration/native-sdks/overview.md): presentano il flusso di verifica al tuo utente e non conservano mai la tua chiave API. Le pagine degli endpoint server dell'[API reference](https://docs.didit.me/it/api-reference/overview.md), comprese le pagine di servizio di [Database Validation](https://docs.didit.me/it/standalone-apis/database-validation.md), mostrano accanto alla richiesta cURL un esempio di codice per ogni SDK server. Un esempio viene mostrato quando l'ultima release dell'SDK include l'endpoint e ogni campo che l'esempio invia: un endpoint o un campo aggiunto all'API riceve i suoi esempi con la release successiva di ogni SDK. Nessuna release 1.0.1 include i 16 campi di richiesta di Database Validation aggiunti dopo la generazione della release 1.0.1, come `vin` o `bank_account_number`, quindi le pagine di servizio che li inviano mostrano solo cURL. ## Installazione ```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 ``` | Linguaggio | Pacchetto | Codice sorgente | Runtime minimo | | - | - | - | - | | [Python](https://docs.didit.me/it/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/it/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 runtime con `fetch` | | [Go](https://docs.didit.me/it/integration/server-sdks/go.md) | [modulo 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/it/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/it/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/it/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/it/integration/server-sdks/dotnet.md) | [NuGet `Didit`](https://www.nuget.org/packages/Didit) | [sdk-dotnet](https://github.com/didit-protocol/sdk-dotnet) | .NET 8 o .NET Standard 2.0 | ## Configurazione Ogni SDK legge le stesse variabili d'ambiente, quindi un client creato senza opzioni è subito pronto all'uso. Gli edge runtime non hanno un ambiente di processo: lì, passa la chiave API al client Node.js come opzione. | Variabile | Usata per | | - | - | | `DIDIT_API_KEY` | Ogni chiamata che usa la chiave API. Crea la chiave nella console, in [Chiavi API](https://docs.didit.me/it/console/api-keys.md). | | `DIDIT_ORGANIZATION_ID`, `DIDIT_APPLICATION_ID` | Operazioni sotto `/v3/organization/{organization_id}/application/{application_id}/` (casi, reti, report normativi, modelli di report e alcuni strumenti per utenti e aziende). L'SDK compila entrambi gli id di percorso dal client, quindi non li passi per ciascuna chiamata. Senza di essi, queste chiamate falliscono prima che venga inviata alcuna richiesta. | | `DIDIT_LOG=debug` | Registra il metodo, il percorso, lo stato, la durata e l'id della richiesta di ogni richiesta. Corpi e intestazioni non vengono mai registrati. | Tutto ciò che puoi impostare tramite l'ambiente puoi anche passarlo al client, insieme a URL di base, timeout, nuovi tentativi, intestazioni predefinite e un tuo client HTTP. Crea un client per processo e condividilo: mantiene un pool di connessioni ed è sicuro da usare da più thread o task. I metodi `account` ([registrazione programmatica](https://docs.didit.me/it/integration/programmatic-registration.md): registrazione, accesso, organizzazioni e applicazioni) chiamano `https://apx.didit.me/auth/v2` e non inviano mai la tua chiave API. Accedi con `account.login`, poi passa il token di accesso restituito al client come token dell'account. ## Cosa fa ogni SDK * **Risorse e metodi.** Le chiamate seguono le risorse dell'API: `client..(...)`, per esempio `sessions.create`, `sessions.retrieve_decision` o `transactions.create`, con la convenzione di maiuscole e minuscole propria di ogni linguaggio. Gli id di percorso sono argomenti posizionali; il corpo e la query sono un unico insieme di campi con nome. Python, Node.js, PHP e Ruby usano i nomi dei campi dell'API (`workflow_id`); Go, Java e .NET usano la convenzione del proprio linguaggio (`WorkflowID`, `workflowId`, `WorkflowId`). * **Liste.** I metodi di lista scorrono automaticamente tutti i risultati (internamente usano `limit` e `offset`) e rendono disponibile anche ogni pagina tramite `count`, `next`, `previous` e `results`. In Ruby, `auto_paging_each` attraversa tutte le pagine, e `total_count`, `next_url` e `previous_url` di una pagina corrispondono a `count`, `next` e `previous` dell'API. * **File.** I caricamenti (immagini di documenti, selfie, prova di residenza, importazioni) accettano un percorso, byte o uno stream. I download (PDF delle sessioni, report) restituiscono byte o uno stream, mai JSON analizzato. * **Compatibilità in avanti.** Un campo di risposta o un valore di enum che la versione dell'SDK non conosce ancora viene mantenuto ed è leggibile, senza generare errori, così un'aggiunta all'API non interrompe un'integrazione già in uso. * **Webhook.** `webhooks.verify` controlla le intestazioni `X-Signature-V2` e `X-Signature` e il timestamp di una consegna con il tuo segreto del webhook, e restituisce un evento tipizzato. Accetta un elenco di segreti mentre ne ruoti uno. Vedi [Webhook](https://docs.didit.me/it/integration/webhooks.md) per lo schema della firma. * **Autenticazione.** Un helper `Authentication` verifica i token di accesso e token ID firmati dall'emittente di Authentication, e chiama i suoi endpoint per token, sessione e step-up. Non usa mai la tua chiave API. ## Errori, nuovi tentativi e timeout | Errore | Quando | | - | - | | `APIConnectionError`, `APITimeoutError` | Non è arrivata nessuna risposta | | `APIStatusError` | Qualsiasi altra risposta non 2xx, con lo stato, il corpo analizzato, gli header e l'ID della richiesta | | `BadRequestError` 400, `AuthenticationError` 401, `PermissionDeniedError` 403, `NotFoundError` 404, `ConflictError` 409, `UnprocessableEntityError` 422, `RateLimitError` 429, `InternalServerError` 5xx | Sottoclassi di `APIStatusError` | | `WebhookVerificationError` | La consegna di un webhook non ha superato la verifica; il suo `reason` ne spiega il motivo | | `ConfigurationError` | Manca una chiave API, un token dell'account, un ID organizzazione o un ID applicazione | Ogni errore deriva da `DiditError`. In Go, ogni errore implementa l'interfaccia `didit.Error` ed è un tipo puntatore, come `*didit.NotFoundError`. Java, PHP e .NET li nominano con il consueto suffisso `Exception` e scrivono `API` come `Api`: `DiditException`, `ApiStatusException`, `NotFoundException`. Gli SDK ritentano una richiesta non riuscita fino a 2 volte, con backoff esponenziale a partire da 0,5 secondi (jitter completo, al massimo 8 secondi) e rispettando `Retry-After`. `GET`, `HEAD`, `PUT` e `DELETE` vengono ritentati in caso di errori di connessione, timeout, 408, 429 e 5xx. `POST` e `PATCH` vengono ritentati solo su 429 oppure quando la connessione è fallita prima che la richiesta venisse inviata, così un nuovo tentativo non crea mai una seconda sessione o transazione. Il timeout predefinito è di 60 secondi. Ogni risposta espone anche lo stato HTTP grezzo, gli header e l'ID della richiesta. Vedi [Rate limiting](https://docs.didit.me/it/integration/rate-limiting.md) per i limiti alla base del 429. ## Versionamento e supporto * Gli SDK seguono il versionamento semantico, con una regola per le modifiche alle API. Una modifica che rispecchia l'API di Didit è una release minore, anche quando può compromettere il codice tipizzato (un campo il cui tipo è cambiato, un campo che ora può essere null, oppure un endpoint, un campo o un valore di enum rimosso): l'API già si comporta così per ogni chiamante, quindi una versione precedente dell'SDK non è più sicura. Le note di rilascio elencano tali modifiche sotto «Modifiche API che possono compromettere il codice tipizzato». * Una release major riguarda solo una modifica al design dell'SDK stesso: un metodo o una risorsa rinominati o rimossi mentre l'API li mantiene, una modifica alla configurazione del client, al comportamento degli errori, dei nuovi tentativi, della paginazione o della verifica dei webhook, oppure una versione del runtime non più supportata. Quando un endpoint esce dall'API o un suo metodo viene rinominato, il vecchio metodo resta per almeno un'altra release minore, contrassegnato come deprecato, così il tuo codice continua a compilare mentre passi a quello nuovo. Ogni linguaggio mantiene il proprio numero di versione: Node.js, PHP e Ruby sono alla 2.x e gli altri alla 1.x, perché questi tre hanno rilasciato una modifica API come release major prima che questa regola esistesse. * Sono generati dal contratto API pubblicato ([`openapi-25.json`](https://docs.didit.me/openapi-25.json) e [`openapi-auth.json`](https://docs.didit.me/openapi-auth.json)), e i loro metodi [Didit Authentication](https://docs.didit.me/it/authentication/overview.md) sono verificati rispetto a [`openapi-authentication.json`](https://docs.didit.me/openapi-authentication.json). Controllano tutti e tre ogni giorno, quindi un nuovo endpoint o campo arriva in una release regolare di tutti e sette gli SDK. * Ogni SDK supporta il runtime minimo indicato nella tabella e tutte le release più recenti. I suoi test vengono eseguiti sul runtime minimo e su ogni release più recente, oppure su ogni release con supporto a lungo termine per Node.js e Java. * Il file `CHANGELOG.md` di ogni repository elenca le modifiche di ogni release. * Segnala un problema di sicurezza in privato tramite gli avvisi di sicurezza del repository dell'SDK oppure a [support@didit.me](mailto:support@didit.me). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.