Skip to main content
Le SDK Python permet aux applications Python d’accéder à l’API REST de Dodo Payments avec un typage. Il comprend un client synchrone, DodoPayments, et un client asynchrone, AsyncDodoPayments, tous deux basés sur httpx. Les paramètres de requête imbriqués sont des dictionnaires typés et les réponses sont des modèles Pydantic.

Installation

Installez le SDK avec pip :
Pour utiliser aiohttp comme backend HTTP du client asynchrone, installez l’extra aiohttp :
Pour vérifier les signatures des webhooks avec client.webhooks.unwrap(), installez également l’extra webhooks : pip install "dodopayments[webhooks]".
Le SDK nécessite Python 3.9 ou une version ultérieure. Utilisez la dernière version stable de Python pour bénéficier des mises à jour de sécurité.

Démarrage rapide

Client synchrone

Créez un client, puis créez une session de paiement :
Si vous omettez bearer_token, le client lit la variable d’environnement DODO_PAYMENTS_API_KEY. Si vous omettez environment, le client se connecte au mode live. Une clé API de mode test ne fonctionne qu’avec environment="test_mode".

Client asynchrone

AsyncDodoPayments possède les mêmes méthodes que DodoPayments. Attendez chaque appel :
Conservez les clés API dans des variables d’environnement ou un gestionnaire de secrets. Ne les validez jamais dans le contrôle de version.

Fonctionnalités principales

Pythonic Interface

Des arguments nommés pour les paramètres, des types TypedDict pour les objets imbriqués et des modèles Pydantic pour les réponses.

Async/Await

AsyncDodoPayments pour asyncio, avec aiohttp comme backend HTTP facultatif.

Type Hints

Des annotations de type sur chaque méthode, pour la complétion automatique de l’éditeur et la vérification des types avec mypy.

Auto-Pagination

Les méthodes de liste renvoient des itérateurs qui récupèrent la page suivante au fur et à mesure de la boucle.

Configuration

Variables d’environnement

Stockez votre clé API dans une variable d’environnement :
.env
Le client lit ces variables lorsque vous ne transmettez pas l’argument correspondant : Si DODO_PAYMENTS_BASE_URL est défini et que vous transmettez également environment, le constructeur renvoie une erreur “Ambiguous URL”. Pour utiliser environment dans ce cas, transmettez base_url=None. Pour vérifier un webhook, transmettez le corps brut de la requête et les en-têtes à client.webhooks.unwrap(payload, headers=headers). Cette méthode vérifie la signature avec votre clé de webhook et renvoie l’événement analysé. client.webhooks.unsafe_unwrap(payload) analyse le corps sans le vérifier ; utilisez-la donc uniquement pour les tests. Consultez Webhooks.

Délais d’expiration

Les requêtes expirent par défaut après 1 minute, avec un délai d’expiration de connexion de 5 secondes. Transmettez timeout en secondes, ou un httpx.Timeout pour définir séparément les limites de lecture, d’écriture et de connexion :
Lorsqu’une requête expire, le SDK lève APITimeoutError. Les requêtes ayant expiré sont réessayées ; un appel peut donc prendre plus de temps que timeout avant d’échouer.

Nouvelles tentatives

Définissez max_retries sur le client ou sur une seule requête avec with_options() :
Le SDK réessaie les erreurs de connexion ainsi que les réponses dont le statut est 408, 409, 429 ou 500 et supérieur. Il effectue par défaut deux nouvelles tentatives, avec un délai exponentiel. Lorsqu’une requête échoue encore, le SDK lève une sous-classe de dodopayments.APIError : Les exceptions liées au statut héritent de dodopayments.APIStatusError, qui possède les attributs status_code et response. APITimeoutError est une sous-classe de APIConnectionError.

Opérations courantes

Les exemples de cette section utilisent client de la section Démarrage rapide.

Créer une session de paiement

Créez une session de paiement, puis redirigez le client vers checkout_url renvoyé :
Chaque checkout_url ne fonctionne qu’une seule fois et expire après 24 heures. Pour connaître toutes les options de session, consultez Sessions de paiement.

Gérer les clients

Créez un client avec une adresse e-mail et un nom, puis récupérez-le par son ID :

Gérer les abonnements

Créez un abonnement, facturez un abonnement à la demande et consultez l’historique d’utilisation d’un abonnement.
POST /subscriptions (la méthode subscriptions.create du SDK) est obsolète. Elle fonctionne toujours pour les intégrations existantes, mais les nouvelles intégrations doivent créer des abonnements via une session de paiement.
billing nécessite uniquement country, un code pays ISO à deux lettres. customer accepte {"customer_id": ...} pour associer un client existant ou {"email": ..., "name": ...} pour en créer un. charge est destiné aux abonnements à la demande, et product_price est exprimé dans la plus petite unité monétaire. retrieve_usage_history renvoie une liste paginée que vous pouvez parcourir comme indiqué dans Pagination.

Facturation basée sur l’utilisation

Ingérer des événements d’utilisation

Envoyez des événements d’utilisation pour un client :
event_id est la clé d’idempotence ; attribuez donc une valeur unique à chaque événement. Si le même event_id apparaît deux fois dans une requête, toute la requête est rejetée. Si un event_id a déjà été ingéré, le nouvel événement est ignoré. Une requête accepte jusqu’à 1 000 événements. timestamp prend par défaut l’heure actuelle et est rejeté s’il date de plus d’une heure ou s’il est situé à plus de 5 minutes dans le futur.

Répertorier et récupérer les événements

Récupérez un événement individuel par son event_id ou répertoriez les événements filtrés par client et par nom d’événement :
usage_events.list accepte également les filtres meter_id, start et end.

Pagination

Pagination automatique

Les méthodes de liste renvoient un itérateur qui récupère la page suivante au fur et à mesure de la boucle :

Pagination asynchrone

Avec le client asynchrone, effectuez la boucle avec async for :

Pagination manuelle

Pour traiter une page à la fois, lisez items et appelez has_next_page() et get_next_page(). next_page_info() renvoie les paramètres de la requête suivante :

Configuration du client HTTP

Pour ajouter un proxy, un transport personnalisé ou d’autres paramètres httpx, transmettez votre propre http_client. DefaultHttpxClient conserve les limites de connexion, le délai d’expiration et les paramètres de redirection par défaut du SDK :
Pour utiliser un autre client HTTP pour une requête, appelez client.with_options(http_client=...).

Async avec AIOHTTP

Par défaut, le client asynchrone envoie les requêtes avec httpx. Pour améliorer la concurrence, installez l’extra aiohttp et transmettez DefaultAioHttpClient() comme http_client :

Journalisation

Le SDK journalise les événements avec le module de la bibliothèque standard logging. Pour activer la journalisation, définissez DODO_PAYMENTS_LOG sur info :
Pour obtenir plus de détails, définissez-le sur debug :

Intégration aux frameworks

Ces exemples créent une session de paiement à partir d’un endpoint web et renvoient son URL.

FastAPI

Cet endpoint utilise le client asynchrone :

Django

Cette vue utilise le client synchrone :

Ressources

GitHub Repository

Code source, versions et liste complète des méthodes.

API Reference

Tous les endpoints, paramètres et réponses.

Discord Community

Posez vos questions et échangez avec d’autres développeurs.

Report Issues

Signalez des bugs ou demandez des fonctionnalités.

Assistance

Pour obtenir de l’aide concernant le SDK Python :

Contribution

Pour contribuer, consultez les directives de contribution.
Dernière modification le 26 septembre 2026