Skip to main content
Il TypeScript SDK offre al codice TypeScript e JavaScript lato server un accesso tipizzato alla REST API di Dodo Payments. Include definizioni dei tipi per ogni request e response, errori tipizzati, retry automatici, timeout e auto-pagination.

Installazione

Installa il pacchetto dodopayments con il tuo package manager:

Avvio rapido

Crea un client, quindi crea una checkout session:
Se ometti bearerToken, il client legge la variabile d’ambiente DODO_PAYMENTS_API_KEY. Se ometti environment, il client si connette alla modalità live. Una API key della modalità test funziona solo con environment: 'test_mode'.
Conserva le API key nelle variabili d’ambiente o in un secrets manager. Non inserirle mai nel version control né esporle nel codice lato client.

Funzionalità principali

TypeScript First

Definizioni dei tipi per ogni parametro di request e campo di response, visualizzate nel tuo editor.

Auto-Pagination

I metodi List recuperano automaticamente la pagina successiva quando esegui l’iterazione con for await...of.

Error Handling

Una classe di errore tipizzata per ogni status error HTTP, con status, headers e response body.

Smart Retries

Due retry per impostazione predefinita, con exponential backoff, per gli errori di connessione e gli status code ritentabili.

Configurazione

Variabili d’ambiente

Salva la tua API key in una variabile d’ambiente:
.env
Il client legge queste variabili quando non passi l’opzione corrispondente: Se è impostato un base URL e passi anche environment, il constructor genera un errore “Ambiguous URL”. Per usare environment in questo caso, passa baseURL: null. Per verificare un webhook, passa il raw request body e gli headers a client.webhooks.unwrap(rawBody, { headers }). Controlla la signature con la tua webhook key e restituisce l’evento analizzato. client.webhooks.unsafeUnwrap(rawBody) analizza il body senza verificarlo, quindi usalo solo per i test. Consulta Webhooks.

Configurazione del timeout

Per impostazione predefinita, le request scadono dopo 1 minuto. Imposta timeout, in millisecondi, sul client o su una singola request:
Quando una request va in timeout, l’SDK genera APIConnectionTimeoutError. Le request scadute vengono ritentate, quindi una chiamata può richiedere più tempo di timeout prima di fallire.

Configurazione dei retry

Imposta maxRetries sul client o su una singola request:
L’SDK ritenta gli errori di connessione e le response con status 408, 409, 429 oppure 500 e superiori. Per impostazione predefinita, esegue due retry con exponential backoff.
Quando una request continua a fallire, l’SDK genera una sottoclasse di DodoPayments.APIError. Ogni errore include le proprietà status, headers e error (il response body). Verifica la presenza di una classe specifica con instanceof, ad esempio err instanceof DodoPayments.RateLimitError:

Operazioni comuni

Gli esempi di questa sezione usano client da Avvio rapido.

Creare una Checkout Session

Crea una checkout session, quindi reindirizza il customer all’checkout_url restituito:
Ogni checkout_url funziona una sola volta e scade dopo 24 ore. Per tutte le opzioni della sessione, consulta Checkout Sessions.

Gestire i Customer

Crea un customer con un indirizzo email e un nome, quindi recuperalo tramite ID:

Gestire le Subscription

Crea una subscription, addebita una subscription on-demand e leggi la cronologia dell’utilizzo di una subscription.
POST /subscriptions (il metodo subscriptions.create dell’SDK) è deprecato. Continua a funzionare per le integrazioni esistenti, ma le nuove integrazioni devono creare le subscription tramite una Checkout Session.
billing richiede solo country, un codice paese ISO di due lettere. customer accetta { customer_id } per collegare un customer esistente oppure { email, name? } per crearne uno. charge è destinato alle subscription on-demand, mentre product_price è espresso nell’unità più piccola della valuta. retrieveUsageHistory restituisce un elenco paginato, su cui puoi eseguire l’iterazione come descritto in Auto-Pagination.

Fatturazione basata sull’utilizzo

Acquisire gli Usage Events

Invia usage events per un customer:
event_id è la idempotency key, quindi assegna a ogni evento un valore univoco. Se lo stesso event_id compare due volte nella stessa request, l’intera request viene rifiutata. Se un event_id è già stato acquisito, il nuovo evento viene ignorato. Una request accetta fino a 1.000 eventi. timestamp assume per impostazione predefinita l’ora corrente e viene rifiutato se risale a più di 1 ora nel passato o è oltre 5 minuti nel futuro.

Recuperare gli Usage Events

Recupera un singolo evento tramite il suo event_id oppure elenca gli eventi filtrati per customer, nome dell’evento e intervallo temporale:
usageEvents.list accetta anche meter_id e restituisce un elenco paginato.

Configurazione del proxy

Per inviare request tramite un proxy, passa le impostazioni proxy del tuo runtime in fetchOptions.

Node.js (usando Undici)

Passa un ProxyAgent di undici come dispatcher:

Bun

Imposta l’opzione proxy:

Deno

Crea un HTTP client con Deno.createHttpClient e passalo come client:

Logging

Imposta il livello di log con l’opzione del client logLevel oppure con la variabile d’ambiente DODO_PAYMENTS_LOG. L’opzione del client prevale sulla variabile d’ambiente.
Al livello debug, l’SDK registra ogni HTTP request e response, inclusi headers e bodies. Alcuni authentication headers vengono oscurati, ma i dati sensibili nei bodies potrebbero rimanere visibili.
I livelli di log, dal più al meno dettagliato, sono:
  • 'debug': messaggi di debug, informazioni, avvisi ed errori.
  • 'info': messaggi informativi, avvisi ed errori.
  • 'warn': avvisi ed errori. È il valore predefinito.
  • 'error': solo errori.
  • 'off': nessun log.
Per impostazione predefinita, l’SDK registra i log su console. Per usare pino, winston o un’altra logging library, passa il tuo logger come opzione logger; logLevel continua a controllare quali messaggi lo raggiungono. I messaggi di log servono solo per il debugging e il loro formato può cambiare tra una release e l’altra.

Migrazione dal Node.js SDK

Se usi il Node.js SDK legacy, segui la migration guide per eseguire l’upgrade. L’SDK attuale usa l’API fetch integrata invece di node-fetch, richiede Node.js 20, TypeScript 4.9 e Jest 28 o versioni successive e include uno strumento di migrazione che aggiorna la maggior parte del tuo codice.

View Migration Guide

Scopri come eseguire la migrazione dal Node.js SDK al TypeScript SDK

Auto-Pagination

I metodi List restituiscono risultati paginati. Esegui l’iterazione con for await...of per ottenere gli elementi da ogni pagina. L’SDK richiede la pagina successiva quando necessario:
Per lavorare con una pagina alla volta, leggi page.items e chiama hasNextPage() e getNextPage():
Per impostare la dimensione della pagina, passa page_size al metodo List, ad esempio client.payments.list({ page_size: 50 }).

Requisiti

L’SDK supporta TypeScript 4.9 o versioni successive e questi runtime:
  • Browser web (versioni aggiornate di Chrome, Firefox, Safari, Edge e altri)
  • Node.js 20 LTS o versioni successive (non-EOL)
  • Deno 1.28.0 o versioni successive
  • Bun 1.0 o versioni successive
  • Cloudflare Workers
  • Vercel Edge Runtime
  • Jest 28 o versioni successive con l’ambiente "node" (l’ambiente "jsdom" non è supportato)
  • Nitro 2.6 o versioni successive
React Native non è supportato.

Risorse

GitHub Repository

Codice sorgente, release ed elenco completo dei metodi.

API Reference

Ogni endpoint, parametro e response.

Discord Community

Fai domande e parla con altri developer.

Report Issues

Segnala bug o richiedi nuove funzionalità.

Supporto

Per ricevere assistenza sul TypeScript SDK:

Contribuire

Per contribuire, leggi le linee guida per i contributi.
Ultima modifica il 26 settembre 2026