Entitlement-Gewährung
Die Nutzlast, die an Ihren Webhook-Endpunkt gesendet wird, wenn eine Entitlement-Gewährung erstellt, geliefert, fehlschlägt oder widerrufen wird.
Entitlement-Gewährung Webhook-Ereignisse
Diese Ereignisse werden ausgelöst, wann immer sich der Status einer Entitlement-Gewährung eines Kunden ändert, zum Beispiel wenn ein Lizenzschlüssel generiert wird, eine Discord-Rolle zugewiesen wird, ein Download-Link bereitgestellt wird oder der Zugriff widerrufen wird. Abonnieren Sie diese Ereignisse, um Ihre Anwendung mit dem zu synchronisieren, worauf jeder Kunde zugreifen kann.EntitlementGrantResponse Nutzlast, die im untenstehenden Schema dokumentiert ist.
Ereignisauslöser
entitlement_grant.created
Eine Grant-Zeile wurde eingefügt. Der Grant verfügt ab diesem Zeitpunkt immer über eine stabileid, auch wenn sich sein Status ändert. Verwende dieses Event, um zu protokollieren, dass die Erfüllung läuft.
Bei automatisch erfüllten License Keys und Feature Flags wird die Zeile direkt mit ausgefüllten Werten für status: "Delivered" und delivered_at eingefügt. Daher folgen auf ein einzelnes created Event keine weiteren Statusänderungen, sofern der Grant nicht später widerrufen wird.
Bei manuell erfüllten Lizenzschlüsseln (Entitlements mit fulfillment_mode: manual) wird die Zeile mit status: "Pending" und ohne Objekt license_key erstellt — es gibt noch keinen Schlüssel. Dieses Ereignis signalisiert, dass ein Schlüssel auf die Erfüllung wartet. Stelle ihn über POST /grants/{grant_id}/license-key bereit; dadurch wird anschließend entitlement_grant.delivered ausgelöst. Siehe Manual Fulfillment.
Bei jeder anderen Integration wird die Zeile mit status: "Pending" erstellt. Sobald die Zustellung abgeschlossen ist, folgt ein Ereignis delivered oder failed:
- OAuth-basierte Integrationen (Discord, GitHub, Notion) verwenden einen
oauth_url, den der Kunde aufrufen muss, um die Einwilligung abzuschließen. Dodo Payments versucht, ihn bei der Erstellung des Grants zu erstellen, daher kannentitlement_grant.createdihn enthalten; wenn ernullist, wird er ausgefüllt, wenn der Kunde den Accept-Flow über das Customer Portal startet. Der Grant bleibtPending, bis der Kunde ihn autorisiert. - Plattformdirekte Integrationen (Telegram, Framer, Digital Files) befinden sich nur kurz in
Pending, während der Plattformaufruf ausgeführt wird, und wechseln anschließend zuDelivered.
pending zu delivered übergegangen. Der Kunde hat jetzt den Zugriff, der durch die Berechtigung beschrieben wird. Verwenden Sie dieses Ereignis, um abhängige Funktionen in Ihren eigenen Systemen freizuschalten, z. B. um einen Arbeitsbereich bereitzustellen, eine benutzerdefinierte Willkommens-E-Mail zu senden oder eine “erfüllt”-Flagge zu setzen.
Der Grant ist zu Delivered übergegangen, üblicherweise von Pending. Der Kunde hat nun den durch die Berechtigung beschriebenen Zugriff. Verwende dieses Event, um abhängige Funktionen in deinen eigenen Systemen freizuschalten, beispielsweise um einen Workspace bereitzustellen, eine individuelle Willkommens-E-Mail zu senden oder ein „fulfilled“-Flag zu setzen.
Das Feld delivered_at der Payload erfasst, wann die Zustellung abgeschlossen wurde. delivered wird immer ausgelöst, wenn sich der Status eines bestehenden Grants zu Delivered ändert: von Pending, wenn ein fehlgeschlagener OAuth-Grant später erfolgreich ist oder wenn ein widerrufener Grant wiederhergestellt wird. Ein Grant, der bei der Erstellung als Delivered eintrifft, etwa ein automatisch erfüllter License Key, löst nur created aus.
Die Lieferung wurde versucht und ist mit einem nicht wiederholbaren Fehler fehlgeschlagen. Die Felder error_code und error_message erklären das Scheitern. Häufige Ursachen sind ein widerrufenes OAuth-Token, eine verweigerte Plattformberechtigung oder ein fehlendes Ziel (z. B. eine gelöschte Discord-Gilde).
entitlement_grant.revoked
Der Zugriff wurde auf Plattformebene widerrufen: Discord-Rolle entfernt, GitHub-Kollaborateur entfernt, Lizenzschlüssel deaktiviert, Download-URLs für Dateien werden nicht mehr ausgegeben. Dasrevocation_reason Feld zeichnet den Auslöser auf.
Nutzlastvarianten
Dasdata Feld ist immer ein EntitlementGrantResponse Objekt. Zwei Integrationstypen hängen zusätzliche verschachtelte Objekte an:
Das Feld data ist immer ein Objekt vom Typ EntitlementGrantResponse. Die Payload enthält ein Feld integration_type (zum Beispiel license_key, digital_files, discord), sodass du den Grant-Typ direkt erkennen kannst. Drei Integrationstypen enthalten außerdem zusätzliche verschachtelte Objekte:
license_keyist enthalten, wennintegration_typelicense_keyentspricht und ein Schlüssel ausgestellt wurde. Es enthält den generierten Schlüssel, das Ablaufdatum und die Aktivierungsnutzung. Bei einem manuell erfüllten Grant, der nochPendingist, lautet dieses Objektnull, bis du den Grant erfüllst.digital_product_deliveryist enthalten, wennintegration_typedigital_filesentspricht. Es enthält vorab signierte Download-URLs, das optionaleinstructionsund das optionaleexternal_url.featureist enthalten, wennintegration_typefeature_flagentspricht. Es enthältfeature_typeundfeature_idder durch den Grant gewährten Funktionalität.
null. Die relevante Konfiguration ist im Entitlement selbst und nicht im Grant enthalten.
Beispiel-Nutzlasten
Lizenzschlüssel geliefert (entitlement_grant.delivered)
License Key zugestellt (entitlement_grant.delivered)
License Key wartet auf manuelle Erfüllung (entitlement_grant.created)
Wird ausgelöst, wenn ein Kunde ein Produkt kauft, dessen License-Key-Entitlement fulfillment_mode: manual verwendet. Der Grant ist Pending und enthält noch kein Objekt license_key — der Merchant muss den Schlüssel bereitstellen.
Digitale Dateien zugestellt (entitlement_grant.delivered)
Discord-Rolle erstellt und ausstehend (entitlement_grant.created)
Grant bei Kündigung des Abonnements widerrufen (entitlement_grant.revoked)
Zustellung fehlgeschlagen (entitlement_grant.failed)
Integrationstipps
- Schalte abhängige Funktionen frei, sobald ein Grant
Deliverederreicht. Einpayment.succeeded-Ereignis teilt dir mit, dass die Zahlung eingegangen ist; es bedeutet nicht, dass der Kunde bereits über das GitHub-Repository oder die Discord-Rolle verfügt. Verarbeiteentitlement_grant.deliveredsowieentitlement_grant.createdmitstatus: "Delivered", da ein bei der Erstellung zugestellter Grant keindelivered-Ereignis auslöst. - Ordne
revocation_reasonden Retention-Flows zu. Einsubscription_on_hold-Revoke bedeutet normalerweise, dass die Karte des Kunden fehlgeschlagen ist und beim nächsten Verlängerungsvorgang erneut Zugriff gewährt wird. Einmanual- odersubscription_cancelled-Revoke ist beabsichtigt. Berücksichtige diesen Unterschied in der Kundenkommunikation. - Erkenne Duplikate anhand des
webhook-id-Headers, nicht anhand des Grant-id. Ein Grant sendetcreatednur einmal, aberdeliveredundrevokedkönnen jeweils mehrmals ausgelöst werden, da ein widerrufener Grant wiederhergestellt und erneut widerrufen werden kann.failedist ebenfalls nicht immer endgültig: Ein fehlgeschlagener OAuth-Grant kann dennoch zugestellt werden. Erneute Zustellungen durch das Webhook-System können ebenfalls zu einer Wiederholung eines Ereignisses führen. Überspringe Wiederholungen anhand vonwebhook-idund verwende für deine eigenen Grant-Datensätze den Grant-idals Schlüssel. - Lies
integration_type, um den Grant-Typ zu erkennen. Der Payload enthältintegration_typedirekt (zum Beispiellicense_key,digital_files,discord). Die verschachtelten Objektelicense_keyunddigital_product_deliverywerden ausgefüllt, sobald die jeweiligen Grants zugestellt wurden; ein manuell erfüllter License-Key-Grant bleibtPendingmitintegration_type: "license_key"und einemnulllicense_key, bis du ihn erfüllst. - Zeige bei OAuth-basierten Grants
oauth_urldem Kunden an. Dasentitlement_grant.created-Ereignis für Subscriber-Flows von Discord, GitHub oder Notion kann einoauth_urlund einoauth_expires_atenthalten. Wenn esnullist, warte auf ein späteres Ereignis oder leite den Kunden zum Customer Portal weiter. Sende die URL per E-Mail an den Kunden oder zeige sie in deiner App an, um die Zustellung zu ermöglichen.
Detailed view of a single entitlement grant: who it's for, its lifecycle state, and any integration-specific delivery payload.
Brand id this grant belongs to.
Identifier of the business that owns the grant.
Timestamp when the grant was created.
Identifier of the customer the grant was issued to.
Identifier of the entitlement this grant was issued from.
Unique identifier of the grant.
The integration type of the grant's entitlement (e.g. license_key).
discord, telegram, github, figma, framer, notion, digital_files, license_key, feature_flag Arbitrary key-value metadata recorded on the grant.
Lifecycle status of the grant.
Pending, Delivered, Failed, Revoked Timestamp when the grant was last modified.
Timestamp when the grant transitioned to delivered, when applicable.
Digital-product-delivery payload, present when the entitlement
integration is digital_files.
Machine-readable code reported when delivery failed, when applicable.
Human-readable message reported when delivery failed, when applicable.
Typed feature payload, present only when the entitlement integration is
feature_flag; null for every other integration type.
License-key delivery payload, present when the entitlement integration
is license_key.
Timestamp when oauth_url stops being valid, when applicable.
Customer-facing OAuth URL for OAuth-style integrations. Populated
during the customer-portal accept flow; null until the customer
completes that step, and on grants for non-OAuth integrations.
Identifier of the payment that triggered this grant, when applicable.
Reason recorded when the grant was revoked, when applicable.
Timestamp when the grant transitioned to revoked, when applicable.
Identifier of the subscription that triggered this grant, when applicable.