Skip to main content
Eine Feature-Flag-Berechtigung verwandelt Dodo Payments in einen abrechnungsbewussten Feature-Flag-Speicher. Verknüpfen Sie ein Flag wie advanced_reports mit einem Produkt, und jeder zahlende Kunde erhält eine Gewährung, die Ihre Anwendung über die API prüft oder mithilfe von Webhooks synchron hält. Es gibt keine externe Plattform, keinen OAuth-Schritt und keinen Bereitstellungsschritt: Die Gewährung selbst ist die Fähigkeit.

Was bereitgestellt wird

Nichts verlässt Dodo Payments. Die Gewährung ist das Bereitstellungsergebnis:
  • Beim Kauf erstellt Dodo Payments die Gewährung direkt in Delivered. Sie gelangt niemals in Pending, erfordert keine Aktion des Kunden und hat keinen Bereitstellungsschritt, der fehlschlagen kann.
  • Die Gewährung enthält eine typisierte feature-Nutzlast: { "feature_type": "boolean", "feature_id": "advanced_reports" }. Ihre Anwendung liest feature_id, um zu entscheiden, was freigeschaltet werden soll.
  • Eine Kündigung, Rückerstattung oder manuelle Aufhebung verschiebt die Gewährung nach Revoked, und das Flag verschwindet aus den bereitgestellten Gewährungen des Kunden.
Häufige Anwendungsfälle umfassen planbasierte Feature-Gatings (Pro schaltet Analysen frei), Zusatzfähigkeiten (ein “API-Zugriff”-Upgrade) und Early-Access-Programme, die als Einmalkäufe verkauft werden.
feature_id ist ein von Ihnen gewählter Bezeichner und über Berechtigungen hinweg nicht eindeutig. Zwei Berechtigungen können dieselbe feature_id gewähren, beispielsweise ein monatlicher und ein jährlicher Pro-Plan, die beide advanced_reports gewähren.

Ein Feature-Flag erstellen

1

Open Entitlements

Gehen Sie im Dashboard von Dodo Payments zu Entitlements und klicken Sie auf +, um eine neue Berechtigung zu erstellen. Wählen Sie anschließend Feature Flags.
2

Name the Flag

Geben Sie einen Anzeigenamen für Ihr Dashboard und Ihre Berichte sowie eine Beschreibung ein, damit Ihr Team weiß, was das Flag steuert. Die Feature ID wird von Ihrer Anwendung geprüft. Das Dashboard füllt sie anhand des Anzeigenamens aus (beispielsweise wird aus “API access” api_access), und Sie können sie bearbeiten. Sie darf keine Leerzeichen enthalten.
Neues Feature-Flag-Formular mit Anzeigenamen, Feature-ID, Beschreibung und Metadaten-Schlüssel-Wert-Einträgen

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

3

Add Metadata (Optional)

Aktivieren Sie Meta Data, um eine Schlüssel-Wert-Konfiguration wie Limits, Stufennamen oder Kontingente anzuhängen, die Ihre Anwendung zusammen mit dem Flag erhält. Klicken Sie für jedes Paar auf Add Entry. Siehe Limits mit Metadaten anhängen.
4

Confirm

Klicken Sie auf Bestätigen. Das Flag erscheint in Ihrer Berechtigungsliste, bereit, mit Produkten verknüpft zu werden.
Berechtigungs-Dashboard, das das Feature-Flag “Advanced Reports” mit seinem Aktivitätspaneel zeigt

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

Mit einem Produkt verknüpfen

Öffnen Sie ein Produkt oder erstellen Sie eines und suchen Sie die Karte Entitlements. Klicken Sie auf +, um vorhandene Berechtigungen zu verknüpfen, wählen Sie Ihr Feature-Flag aus und klicken Sie auf Done.
Berechtigungen anhängen-Panel mit dem ausgewählten Feature-Flag “Advanced Reports”

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

Das verknüpfte Flag erscheint im Produktformular, und die Checkout-Vorschau listet es unter Enthalten.
Produktformular mit dem verknüpften Feature-Flag “Advanced Reports” in der Berechtigungen-Karte

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

Erforderliche Konfiguration

Erstellung über API


Limits mit Metadaten anhängen

Ein boolesches Flag beantwortet die Frage: “Hat dieser Kunde diese Funktion?” Metadaten beantworten: “Mit welcher Konfiguration?” Berechtigungsmetadaten akzeptieren Zeichenfolgen-, Ganzzahl-, Zahlen- und boolesche Werte. Jede Gewährung erhält beim Erstellen einen unveränderlichen Snapshot der Metadaten der Berechtigung. Der Snapshot macht Metadaten sicher für Planlimits:
  • Eine spätere Bearbeitung der Metadaten der Berechtigung wirkt sich nur auf zukünftige Gewährungen aus. Kunden behalten die Limits, unter denen sie gekauft haben.
  • Jede Gewährung gibt ihren Snapshot in ihrem Feld metadata zurück, sodass ein API-Aufruf sowohl das Flag als auch seine Konfiguration liefert.
Beispielsweise ermöglicht ein advanced_reports-Flag mit { "tier": "pro", "monthly_report_limit": 100 } Ihrer Anwendung, das Dashboard freizuschalten und das Kontingent von 100 Berichten ohne eine zweite Abfrage durchzusetzen. Wenn Sie das Limit später auf 250 erhöhen, bleiben bestehende Kunden bei 100, bis sie eine neue Gewährung erhalten, beispielsweise nach einem Planwechsel.
Verwenden Sie Metadaten für Limits und Konfiguration und feature_id ausschließlich für die Identität. Wenn Sie ein Limit in der ID codieren (advanced_reports_100), müssen Sie bei jeder Änderung des Limits ein neues Flag erstellen, und die Prüfungen Ihrer Anwendung funktionieren nicht mehr.

Die Funktionen eines Kunden prüfen

Um die Menge der Funktionen eines Kunden zu erstellen, listen Sie seine bereitgestellten Feature-Flag-Gewährungen auf. Der Endpunkt gibt eine Zeile pro Gewährung über alle Berechtigungen hinweg zurück. Sie können sie nach integration_type und status filtern. Diese Beispiele verwenden die client aus Über die API erstellen.
Die feature-Nutzlast wird nur bei feature_flag-Gewährungen ausgefüllt. Für jeden anderen Integrationstyp ist sie null. Die vollständige Antwortstruktur finden Sie in der API-Referenz List Customer Grants.
Die API bei jeder Anfrage aufzurufen, erhöht die Latenz in Ihrem kritischen Pfad. Cachen Sie den Funktionsumfang jedes Kunden mit einer kurzen TTL (Minuten, nicht Stunden) und invalidieren Sie den Cache in Ihrem Webhook-Handler, wenn sich der Status einer Gewährung ändert. Zusammen sorgen diese Maßnahmen für schnelle Prüfungen und dafür, dass Aufhebungen bei der nächsten Anfrage wirksam werden.

Lebenszyklus

Feature-Flag-Gewährungen folgen dem standardmäßigen Lebenszyklus einer Gewährung mit einer Vereinfachung: Es gibt keinen Bereitstellungsschritt, daher verbleiben Gewährungen niemals in Pending und wechseln niemals nach Failed. Gewährungen sind pro Berechtigung und Kunde idempotent. Solange ein Kunde eine nicht aufgehobene Gewährung für ein Flag besitzt, erstellen wiederholte Käufe und Verlängerungen keine Duplikate.

Webhooks

Um Flags in Ihre eigene Datenbank zu übernehmen, anstatt sie regelmäßig abzufragen, abonnieren Sie die entitlement_grant.*-Ereignisse:
  • entitlement_grant.created trifft bereits im Status Delivered mit der feature-Nutzlast ein. Aktivieren Sie die Funktion.
  • entitlement_grant.delivered wird ausgelöst, wenn eine zuvor aufgehobene Gewährung wiederhergestellt wird. Aktivieren Sie die Funktion erneut.
  • entitlement_grant.revoked bedeutet, dass der Zugriff entzogen wurde. Deaktivieren Sie die Funktion und prüfen Sie revocation_reason, um Ihre Nachricht auszuwählen.
Dieser Express-Handler überprüft die Webhook-Signatur mit dem SDK und speichert anschließend den Status des Flags:
TypeScript
Feature Flags lösen niemals entitlement_grant.failed aus, da die Bereitstellung vollständig innerhalb von Dodo Payments erfolgt.

Beispiel: Pro-Plan schaltet erweiterte Berichte frei

  1. Erstellen Sie das Flag. Setzen Sie feature_id: advanced_reports mit den Metadaten { "tier": "pro", "monthly_report_limit": 100 }.
  2. Verknüpfen Sie es mit Ihrem Abonnementprodukt für den Pro-Plan.
  3. Ein Kunde abonniert. Dodo Payments erstellt eine Gewährung im Status Delivered und löst entitlement_grant.created aus. Ihr Webhook-Handler aktiviert advanced_reports für den Kunden mit einem Limit von 100.
  4. Ihre Anwendung schaltet die Funktion frei. Prüfen Sie beim Laden des Dashboards den zwischengespeicherten Funktionsumfang (oder rufen Sie listEntitlementGrants auf) und rendern Sie den Tab für Berichte nur, wenn advanced_reports vorhanden ist.
  5. Der Kunde kündigt. Dodo Payments hebt die Gewährung auf und löst entitlement_grant.revoked aus, woraufhin Ihr Handler die Funktion deaktiviert. Wird ein Abonnement später durch ein Mahnverfahren wiederhergestellt, aktiviert entitlement_grant.delivered die Funktion ohne Codeänderungen erneut.

Best Practices

  • Verwenden Sie stabile Feature-IDs in snake_case. Ihr Anwendungscode prüft diese Zeichenfolgen. Eine Umbenennung ist daher auf beiden Seiten eine inkompatible Änderung.
  • Verwenden Sie ein Flag pro Fähigkeit. Bevorzugen Sie advanced_reports und api_access als zwei Berechtigungen gegenüber einer einzelnen pro_bundle, damit Aufhebungen und Plankombinationen übersichtlich bleiben.
  • Steuern Sie den Status über Webhooks und überprüfen Sie ihn mit der API. Webhooks halten Ihre Datenbank aktuell. Der Listenendpunkt ist die Quelle der Wahrheit für Abgleichsaufgaben und Cache-Fehltreffer.
  • Behandeln Sie Revoked als sofort wirksam. Ein aufgehobenes Flag bedeutet, dass der Kunde nicht länger für die Funktion bezahlt. Sperren Sie sie bei der nächsten Anfrage, nicht erst bei der nächsten Sitzung.
  • Legen Sie Limits in Metadaten statt im Code ab. Wenn Sie ein Kontingent ändern, müssen Sie anschließend nur die Berechtigung bearbeiten. Neue Kunden erhalten den neuen Wert, während bestehende Gewährungen ihren gekauften Snapshot behalten.
Zuletzt geändert am 26. September 2026