Skip to main content
Un droit de feature flag transforme Dodo Payments en plateforme de feature flags consciente de la facturation. Associez un flag tel que advanced_reports à un produit, et chaque client payant reçoit un grant que votre application vérifie via l’API ou synchronise avec les webhooks. Aucune plateforme externe, étape OAuth ou étape de livraison n’est nécessaire : le grant lui-même constitue la capacité.

Ce qui est fourni

Rien ne sort de Dodo Payments. Le grant est le livrable :
  • Lors de l’achat, Dodo Payments crée directement le grant dans Delivered. Il n’entre jamais dans Pending, ne nécessite aucune action du client et ne comporte aucune étape de livraison susceptible d’échouer.
  • Le grant contient un payload feature typé : { "feature_type": "boolean", "feature_id": "advanced_reports" }. Votre application lit feature_id pour décider quoi déverrouiller.
  • Une annulation, un remboursement ou une révocation manuelle fait passer le grant à Revoked, et le flag disparaît des grants fournis au client.
Les utilisations courantes incluent la gestion des fonctionnalités basées sur des plans (Pro débloque les analyses), les capacités supplémentaires (une mise à niveau “accès API”), et les programmes d’accès anticipé vendus sous forme d’achats uniques.
feature_id est un identifiant que vous choisissez et qui n’est pas unique parmi les droits. Deux droits peuvent conférer le même feature_id, par exemple un forfait Pro mensuel et annuel qui accordent tous deux advanced_reports.

Créer un feature flag

1

Open Entitlements

Dans le tableau de bord Dodo Payments, accédez à Entitlements et cliquez sur + pour commencer un nouveau droit, puis choisissez Feature Flags.
2

Name the Flag

Saisissez un Display Name pour votre tableau de bord et vos rapports, ainsi qu’une Description afin que votre équipe sache ce que contrôle le flag. Le Feature ID est la valeur vérifiée par votre application. Le tableau de bord le renseigne à partir du nom d’affichage (par exemple, « API access » devient api_access), et vous pouvez le modifier. Il ne peut pas contenir d’espaces.
Formulaire de nouvelle fonction de fonctionnalité avec nom d'affichage, ID de fonctionnalité, description et entrées de métadonnées

Creating a feature flag. The Feature ID is what your application checks; Meta Data attaches limits alongside the flag.

3

Add Metadata (Optional)

Activez Meta Data pour associer une configuration clé-valeur, comme des limites, des noms de niveaux ou des quotas, que votre application reçoit avec le flag. Cliquez sur Add Entry pour chaque paire. Consultez Associer des limites avec des métadonnées.
4

Confirm

Cliquez sur Confirmer. La fonction apparaît dans votre liste de droits, prête à attacher à des produits.
Tableau de bord des droits avec la fonction de fonctionnalité Rapports Avancés et son panneau d'activité de concession

The created feature flag. The right pane tracks every customer grant issued from it.

Associer à un produit

Ouvrez un produit ou créez-en un, puis recherchez la carte Entitlements. Cliquez sur + pour associer des droits existants, sélectionnez votre feature flag et cliquez sur Done.
Panneau d'attachement des droits avec la fonction de fonctionnalité Rapports Avancés sélectionnée

Attaching the feature flag to a product. One product can deliver multiple entitlements.

La fonction attachée s’affiche sur le formulaire de produit, et la prévisualisation du paiement la répertorie sous Comprend.
Formulaire de produit avec la fonction de fonctionnalité Rapports Avancés attachée dans la carte Droits

The product now includes the feature flag. Every successful purchase or active subscription grants it.

Configuration requise

Créer via API


Associer des limites avec des métadonnées

Un flag booléen répond à la question « Ce client dispose-t-il de cette fonctionnalité ? ». Les métadonnées répondent à la question « Avec quelle configuration ? ». Les métadonnées des droits acceptent les valeurs de type chaîne, entier, nombre et booléen. Chaque grant prend un instantané figé des métadonnées du droit lors de sa création. L’instantané rend les métadonnées sûres pour gérer les limites des forfaits :
  • Modifier ultérieurement les métadonnées du droit n’affecte que les grants futurs. Les clients conservent les limites correspondant à leur achat.
  • Chaque grant renvoie son instantané dans son champ metadata, de sorte qu’un seul appel API vous fournit à la fois le flag et sa configuration.
Par exemple, un flag advanced_reports avec { "tier": "pro", "monthly_report_limit": 100 } permet à votre application de déverrouiller le tableau de bord et d’appliquer le quota de 100 rapports sans seconde recherche. Si vous augmentez ensuite la limite à 250, les clients existants restent à 100 jusqu’à ce qu’ils reçoivent un nouveau grant, par exemple après un changement de forfait.
Utilisez les métadonnées pour les limites et la configuration, et utilisez feature_id uniquement pour l’identité. Encoder une limite dans l’ID (advanced_reports_100) impose de créer un nouveau flag à chaque modification de limite et interrompt les vérifications de votre application.

Vérifier les fonctionnalités d’un client

Pour constituer l’ensemble des fonctionnalités dont dispose un client, listez ses grants de feature flags fournis. L’endpoint renvoie une ligne par grant pour l’ensemble des droits, et vous pouvez le filtrer par integration_type et status. Ces exemples utilisent client de Créer via l’API.
Le payload feature est renseigné uniquement pour les grants feature_flag. Il vaut null pour tous les autres types d’intégration. Consultez la référence API List Customer Grants pour connaître la structure complète de la réponse.
Appeler l’API à chaque requête ajoute de la latence à votre chemin critique. Mettez en cache l’ensemble des fonctionnalités de chaque client avec un TTL court (quelques minutes, et non plusieurs heures), puis invalidez le cache depuis votre gestionnaire de webhook lorsqu’un grant change d’état. Ensemble, ces mesures accélèrent les vérifications et rendent les révocations effectives dès la requête suivante.

Cycle de vie

Les grants de feature flags suivent le cycle de vie standard d’un grant, avec une simplification : il n’y a pas d’étape de livraison. Les grants ne restent donc jamais dans Pending et ne passent jamais à Failed. Les grants sont idempotents par droit et par client. Tant qu’un client dispose d’un grant non révoqué pour un flag, les achats répétés et les renouvellements ne créent pas de doublons.

Webhooks

Pour répliquer les flags dans votre propre base de données plutôt que d’effectuer des interrogations périodiques, abonnez-vous aux événements entitlement_grant.* :
  • entitlement_grant.created arrive déjà Delivered, avec le payload feature. Activez la fonctionnalité.
  • entitlement_grant.delivered est déclenché lorsqu’un grant précédemment révoqué est restauré. Activez à nouveau la fonctionnalité.
  • entitlement_grant.revoked signifie que l’accès a été retiré. Désactivez la fonctionnalité et vérifiez revocation_reason pour choisir votre message.
Ce gestionnaire Express vérifie la signature du webhook avec le SDK, puis enregistre l’état du flag :
TypeScript
Les feature flags ne déclenchent jamais entitlement_grant.failed, car la livraison s’effectue entièrement dans Dodo Payments.

Exemple : le forfait Pro déverrouille les rapports avancés

  1. Créez le flag. Définissez feature_id: advanced_reports avec les métadonnées { "tier": "pro", "monthly_report_limit": 100 }.
  2. Associez-le à votre produit d’abonnement Pro Plan.
  3. Un client s’abonne. Dodo Payments crée un grant Delivered et déclenche entitlement_grant.created. Votre gestionnaire de webhook active advanced_reports pour le client avec une limite de 100.
  4. Votre application contrôle l’accès à la fonctionnalité. Lors du chargement du tableau de bord, vérifiez l’ensemble des fonctionnalités mis en cache (ou appelez listEntitlementGrants) et affichez l’onglet des rapports uniquement lorsque advanced_reports est présent.
  5. Le client annule. Dodo Payments révoque le grant et déclenche entitlement_grant.revoked ; votre gestionnaire désactive alors la fonctionnalité. Si un abonnement est ensuite rétabli grâce au recouvrement, entitlement_grant.delivered restaure la fonctionnalité sans modification du code.

Bonnes pratiques

  • Utilisez des Feature IDs stables dans snake_case. Le code de votre application vérifie ces chaînes ; en renommer une constitue donc une modification incompatible des deux côtés.
  • Utilisez un flag par capacité. Préférez advanced_reports et api_access comme deux droits plutôt qu’un seul pro_bundle, afin que les révocations et les combinaisons de forfaits restent simples.
  • Pilotez l’état depuis les webhooks et vérifiez-le avec l’API. Les webhooks maintiennent votre base de données à jour. L’endpoint de liste est la source de vérité pour les tâches de rapprochement et les absences du cache.
  • Traitez Revoked comme immédiat. Un flag révoqué signifie que le client ne paie plus pour la fonctionnalité. Contrôlez l’accès dès la requête suivante, et non à la session suivante.
  • Placez les limites dans les métadonnées, pas dans le code. Pour modifier un quota, il suffit alors de modifier le droit. Les nouveaux clients obtiennent la nouvelle valeur et les grants existants conservent l’instantané acheté.
Dernière modification le 26 septembre 2026