> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dodopayments.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Introduction
> Distribuez automatiquement des clés de licence, des fichiers téléchargeables, des flags de fonctionnalité et l'accès à des plateformes comme Discord, GitHub, Telegram, Framer et Notion lorsque les clients paient.
Les droits convertissent un paiement réussi ou un abonnement actif en accès réel : une clé de licence dans la boîte de réception de votre client, un flag de fonctionnalité que votre application vérifie, un rôle Discord, un dépôt GitHub, un modèle Notion, un lien de remix Framer, une invitation à un chat Telegram ou un ensemble de fichiers téléchargeables. Dodo Payments émet, suit et révoque cet accès automatiquement au fur et à mesure que le cycle de vie du paiement évolue.
## Qu'est-ce que les Droits ?
Un **droit** est une définition réutilisable de quelque chose que vous livrez à un client : une clé de licence Pro, un rôle Discord "Patrons", l'accès à votre dépôt GitHub privé, un lot d'e-books téléchargeables. Vous attachez des droits à des produits, et Dodo Payments s'occupe du reste.
Lorsqu'un client achète le produit, Dodo Payments crée une **concession**, une émission unique de ce droit à un client. Les concessions passent par un petit ensemble de statuts : `pending` pendant que la livraison est en cours, `delivered` une fois que le client a accès, `failed` si la livraison n'a pas pu être complétée, et `revoked` lorsque l'accès est retiré.
Les droits contrôlent **l'accomplissement** (le client a-t-il accès ?). Les crédits contrôlent **la consommation** (combien peuvent-ils utiliser ?). Les deux peuvent être attachés au même produit. Voir [Facturation par crédit](/features/credit-based-billing) pour les crédits.
## Intégrations Disponibles
Dodo Payments livre chaque droit via une intégration dédiée. Choisissez l'intégration qui correspond à ce que vous vendez.
Générez des clés de licence uniques avec des limites d'activation et d'expiration. Idéal pour les logiciels, les plugins et les CLIs.
Distribuez des fichiers téléchargeables (e-books, modèles, médias) avec des URLs de téléchargement présignées et des instructions optionnelles.
Protégez des fonctionnalités dans votre propre application à la suite d'un achat. Livrée instantanément, vérifiée via API, révoquée en cas d'annulation.
Attribuez à un client un rôle sur votre serveur Discord lors de son achat. Révocation automatique en cas d'annulation.
Ajoutez des clients comme collaborateurs à un dépôt privé avec le niveau de permission que vous choisissez.
Ajoutez des clients à un chat ou canal Telegram privé après l'achat.
Débloquez un lien de remix de modèle Framer pour les clients payants.
Dupliquez un modèle Notion dans l'espace de travail du client lors de l'achat.
***
## Comment fonctionnent les Grants
Les grants sont pilotés par les mêmes événements de paiement et d'abonnement que vous recevez déjà en tant que webhooks. Vous n'avez pas besoin d'appeler l'API de grant vous-même pour les achats. Dodo Payments crée et révoque les grants automatiquement en fonction du cycle de vie des paiements sous-jacent.
### Cycle de vie des Grants
Un grant est créé lorsqu'un paiement est complété ou un abonnement devient actif. Les clés de licence et les flags de fonctionnalité passent directement à `delivered`. Toute autre intégration démarre à `pending`. Les intégrations basées sur OAuth (Discord, GitHub, Notion) incluent un `oauth_url` que le client doit visiter pour compléter le consentement. Les intégrations directes en ligne (Telegram, Framer, fichiers numériques) restent en `pending` seulement brièvement pendant que la livraison est provisionnée, puis passent à `delivered`.
Une fois la livraison terminée (clé de licence générée, rôle attribué, accès au dépôt accordé, liens de fichiers résolus, OAuth complété), le grant passe à `delivered` et `delivered_at` est défini.
Si l'appel d'intégration renvoie une erreur non relançable (jeton OAuth révoqué, permission refusée, fichier n'existe plus), le grant passe à `failed`. Les champs `error_code` et `error_message` capturent la raison.
Lorsque l'accès est retiré (abonnement annulé, remboursement émis, ou révocation initiée par le marchand), le grant passe à `revoked`. Le champ `revocation_reason` enregistre le déclencheur.
### Comportement des Grants par Événement
| Event | Comportement |
| -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `payment.succeeded` (paiement ponctuel) | Émet un grant par droit attaché. |
| `payment.succeeded` (paiement lié à un abonnement) | Aucun effet. Les grants sont pilotés par l'événement d'abonnement ci-dessous. |
| `subscription.active` | Émet des grants pour tous les droits attachés qui n'en ont pas déjà un. Réaccorder tous les grants précédemment révoqués pour le même abonnement. |
| `subscription.renewed` | Aucun effet. Les grants existants persistent lors des renouvellements. |
| `subscription.on_hold` | Révoquez tous les grants délivrés et en attente. `revocation_reason: subscription_on_hold`. |
| `subscription.cancelled` | Révoquer tous. `revocation_reason: subscription_cancelled`. |
| `subscription.expired` | Révoquer tous. `revocation_reason: subscription_expired`. |
| `subscription.plan_changed` | Révoquer tous les grants actuels, puis émettre des grants pour les droits du nouveau plan. `revocation_reason: plan_changed`. |
| `refund.succeeded` (paiement ponctuel) | Révoquer les grants pour ce paiement. `revocation_reason: refund`. |
| Révocation API manuelle | Révoquer avec `revocation_reason: manual`. Les révocations manuelles ne sont pas réaccordées automatiquement lors du renouvellement de l'abonnement. |
| Clé de licence désactivée | Pour les grants de clé de licence, la désactivation de la clé sous-jacente révoque le grant avec `revocation_reason: license_key_disabled`. Le grant est réactivé automatiquement si la clé est réactivée. |
| Dérive de plateforme détectée | Si le côté plateforme d'une intégration sort de la synchronisation (un rôle Discord enlevé manuellement, l'App GitHub perdant l'accès au dépôt, ou un passage de réconciliation détectant une cible manquante), le grant est révoqué avec `revocation_reason: platform_external`. Pas de réattribution automatique lors du renouvellement de l'abonnement tant que le problème de plateforme sous-jacent n'est pas résolu. |
Les grants pilotés par abonnement sont idempotents par `(entitlement, customer, subscription)`; les renouvellements et réactivations ne créent pas de grants en double. Les grants ponctuels sont idempotents par `(entitlement, customer, payment)`.
***
## Créez votre premier droit
Accédez à **Droits** dans votre tableau de bord Dodo Payments et cliquez sur **+** pour créer un nouveau droit.
Choisissez le type d'intégration : Clé de licence, Fichiers numériques, Flag de fonctionnalité, Discord, GitHub, Telegram, Framer ou Notion. Pour les intégrations de plateforme, connectez d'abord votre compte si vous ne l'avez pas déjà fait.
Remplissez les champs spécifiques à l'intégration. Par exemple, GitHub demande un dépôt et un niveau de permission ; Discord demande un serveur et un rôle optionnel ; la Clé de licence demande des limites d'activation et d'expiration.
Enregistrez le droit. Vous pouvez maintenant l'attacher à n'importe quel produit.
## Attacher des Droits aux Produits
Ouvrez un produit, développez **Paramètres avancés → Droits & Crédits**, et sélectionnez les droits qui doivent être délivrés lorsque le produit est acheté. Un seul produit peut délivrer plusieurs droits à la fois. Par exemple, un plan Pro peut inclure une clé de licence, un accès GitHub et un rôle Discord.
***
## Expérience Client
### Email et portail client
Les clients reçoivent un email de livraison après l'achat contenant la clé de licence, les liens de téléchargement, les liens d'invitation OAuth ou l'invitation à la plateforme, selon ce qui s'applique aux droits du produit. Les mêmes détails restent disponibles indéfiniment depuis le [Portail Client](/features/customer-portal) dans leur historique de commandes.
### Livraison basée sur OAuth
L'accès aux abonnés Discord, GitHub et Notion nécessite que le client autorise Dodo Payments à leur donner l'accès. Ces grants restent en statut `pending` jusqu'à ce que le client complète le flux OAuth à l'aide du lien de son email ou du portail client. Une fois qu'ils autorisent, le grant passe à `delivered` et l'accès à la plateforme est provisionné immédiatement.
### Révocation
Les grants révoqués sont supprimés au niveau de la plateforme : le rôle Discord est retiré, le collaborateur GitHub est retiré, la clé de licence est désactivée. Les clients voient le changement reflété dans le portail client.
Pour les fichiers numériques, la révocation supprime l'accès aux URL pré-signées à l'avenir mais ne rend pas invalides les copies qu'un client a déjà téléchargées. Planifiez le contenu de manière appropriée.
***
## Gérer les Grants
Ouvrez n'importe quel droit à partir du tableau de bord pour voir ses grants. Le panneau de détails du grant montre les grants totaux, les filtres de statut, les informations client, les dates de livraison et une action de révocation.
Vous pouvez également gérer les grants de manière programmatique :
```typescript TypeScript theme={null} theme={null}
import DodoPayments from 'dodopayments';
const client = new DodoPayments({
bearerToken: process.env['DODO_PAYMENTS_API_KEY'],
});
// List grants for an entitlement
const grants = await client.entitlements.grants.list('ent_abc123', {
status: 'Delivered',
});
// Revoke a single grant
await client.entitlements.grants.revoke('grant_xyz789', {
id: 'ent_abc123',
});
```
```python Python theme={null} theme={null}
client.entitlements.grants.list(
"ent_abc123",
status="Delivered",
)
client.entitlements.grants.revoke(
"grant_xyz789",
id="ent_abc123",
)
```
```go Go theme={null} theme={null}
grants, _ := client.Entitlements.Grants.List(
ctx, "ent_abc123",
dodopayments.EntitlementGrantListParams{Status: dodopayments.F("delivered")},
)
_, _ = client.Entitlements.Grants.Revoke(ctx, "grant_xyz789", "ent_abc123")
```
***
## Gestion par API
Créez un nouveau droit de tout type d'intégration.
Listez les droits avec filtrage par type d'intégration.
Récupérez un droit et sa configuration résolue.
Mettez à jour le nom, la description ou la configuration de l'intégration.
Supprimez un droit en douceur ; les grants existants ne sont pas affectés.
Téléchargez un fichier vers un droit de fichiers numériques (jusqu'à 500 MiB).
Listez tous les grants pour un droit avec des filtres de statut et de clients.
Révoquez manuellement un seul grant.
***
## Webhooks
Dodo Payments déclenche quatre événements webhook pour le cycle de vie des grants. Abonnez-vous à ces événements pour garder votre application en synchronisation avec ce que chaque client peut accéder.
| Event | Déclenche quand |
| ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `entitlement_grant.created` | Un nouveau grant est créé. Les grants de clé de licence arrivent `delivered`; toute autre intégration arrive `pending` et passe à `delivered` une fois que l'appel plateforme réussit (ou, pour les intégrations basées sur OAuth, une fois que le client autorise). |
| `entitlement_grant.delivered` | Le grant passe à délivré. Le client a maintenant accès. |
| `entitlement_grant.failed` | Le grant n'a pas pu être délivré. Inspectez `error_code` et `error_message`. |
| `entitlement_grant.revoked` | L'accès a été retiré. Inspectez `revocation_reason`. |
Consultez le schéma de charge utile complet, les événements d'exemple et `revocation_reason` référence.
***
## Bonnes pratiques
* **Utilisez un droit par canal de livraison.** Ne partagez pas un seul droit Discord sur des produits avec différentes intentions de rôle; créez-en un par rôle pour une révocation propre.
* **Testez en mode test d'abord.** Créez le droit, attachez-le à un produit test, effectuez un paiement, et observez le grant passer par `pending → delivered`. Confirmez que l'annulation de l'abonnement test révoque le grant.
* **Écoutez `entitlement_grant.delivered`, pas `payment.succeeded`.** Un paiement peut réussir avant que l'exécution ne soit terminée (surtout pour les flux OAuth). Attendez l'événement de livraison avant de débloquer les fonctionnalités dépendantes dans vos propres systèmes.
* **Traitez `entitlement_grant.failed` comme actionnable.** Un grant échoué signifie qu'un client a payé mais n'a pas reçu l'accès. Affichez ces informations à votre équipe de support ou déclenchez un regrant.
* **Mappez `revocation_reason` à vos flux de rétention.** Un `subscription_on_hold` révoquer est récupérable (le client peut mettre à jour sa carte). Un `manual` révoquer est intentionnel. Traitez-les différemment dans vos communications clients.