Die Nutzlast, die an Ihren Webhook-Endpunkt gesendet wird, wenn eine Entitlement-Gewährung erstellt, geliefert, fehlschlägt oder widerrufen wird.
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.
| Ereignis | Beschreibung |
|---|---|
entitlement_grant.created | Eine neue Gewährungszeile wurde erstellt. Der Status ist delivered sofort für Lizenzschlüssel und pending für jede andere Integration. |
entitlement_grant.delivered | Die Gewährung wechselt zu „geliefert“. Der Kunde hat jetzt Zugriff auf die berechtigte Plattform, Datei oder den Lizenzschlüssel. |
entitlement_grant.failed | Die Lieferung ist fehlgeschlagen und wird nicht erneut versucht. Überprüfen Sie error_code und error_message. |
entitlement_grant.revoked | Der Zugriff wurde entzogen. Überprüfen Sie revocation_reason, um zu verstehen warum. |
EntitlementGrantResponse Nutzlast, die im untenstehenden Schema dokumentiert ist.
id, auch wenn sich ihr Status ändert. Verwenden Sie dieses Ereignis, um zu protokollieren, dass die Erfüllung in Arbeit ist.
Für Lizenzschlüssel wird die Zeile direkt mit status: "delivered" und delivered_at eingefügt, sodass ein einziges created Ereignis keiner weiteren Statusänderungen folgt, es sei denn, die Gewährung wird später widerrufen.
Für jede andere Integration kommt die Zeile mit status: "pending" an. Ein delivered oder failed Ereignis folgt, sobald die Lieferung abgeschlossen ist:
oauth_url, das der Kunde besuchen muss, um die Zustimmung abzuschließen. Die Gewährung bleibt pending, bis der Kunde autorisiert.pending, während der Plattformaufruf läuft, und wechseln dann zu delivered.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.
Das delivered_at Feld der Nutzlast erfasst, wann die Lieferung abgeschlossen wurde. Für Gewährungen, die bei Erstellung delivered angekommen sind, erhalten Sie created und delivered Ereignisse hintereinander.
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).
revocation_reason Feld zeichnet den Auslöser auf.
revocation_reason | Auslöser |
|---|---|
subscription_cancelled | Das Abonnement des Kunden wurde storniert (subscription.cancelled Ereignis). |
subscription_on_hold | Das Abonnement ist aufgrund eines fehlgeschlagenen Erneuerungsversuchs angehalten (subscription.on_hold). Wiederherstellbar: Ein erfolgreicher erneuter Versuch führt zu einer Neugewährung. |
subscription_expired | Das Abonnement hat sein Ende der Laufzeit erreicht (subscription.expired). |
plan_changed | Der Plan hat sich geändert; alte Gewährungen werden widerrufen, bevor neue ausgestellt werden (subscription.plan_changed). |
refund | Eine Rückerstattung wurde für die ursprüngliche Einmalzahlung verarbeitet (refund.succeeded). |
manual | Ein Händler hat die Gewährung über die API oder das Dashboard widerrufen. Manuelle Widerrufe werden bei Abonnementerneuerung nicht automatisch neu gewährt. |
license_key_disabled | Der Lizenzschlüssel hinter einer Lizenzschlüssel-Gewährung wurde deaktiviert. Die Gewährung wird automatisch reaktiviert, wenn der Schlüssel wieder aktiviert wird. |
platform_external | Die Plattform-Seite einer Integration ist aus der Synchronisation geraten (zum Beispiel wurde eine Discord-Rolle manuell entfernt, die GitHub-App hat den Repository-Zugriff verloren, oder ein Abgleichsprozess hat ein fehlendes Ziel erkannt). Die Gewährung wird bei Abonnementerneuerung nicht automatisch neu gewährt, bis das zugrunde liegende Plattformproblem gelöst ist. |
data Feld ist immer ein EntitlementGrantResponse Objekt. Zwei Integrationstypen hängen zusätzliche verschachtelte Objekte an:
license_key wird beigefügt, wenn der Typ der Entitlement-Integration license_key ist. Es enthält den generierten Schlüssel, das Ablaufdatum und die Aktivierungsnutzung.digital_product_delivery wird beigefügt, wenn der Integrationstyp digital_files ist. Es enthält signierte Download-URLs, das optionale instructions und das optionale external_url.null; die relevante Konfiguration wird in der Berechtigung selbst erfasst, nicht in der Gewährung.
entitlement_grant.delivered)entitlement_grant.delivered)entitlement_grant.created)entitlement_grant.revoked)entitlement_grant.failed)entitlement_grant.delivered, bevor Sie abhängige Funktionen freischalten. Ein payment.succeeded Ereignis sagt Ihnen, dass das Geld eingegangen ist; es sagt Ihnen nicht, dass der Kunde das GitHub-Repo oder die Discord-Rolle bereits hat. Das delivered Ereignis ist die maßgebliche Quelle für die Erfüllung.revocation_reason Retentionsflüssen zu. Ein subscription_on_hold Widerruf bedeutet normalerweise, dass die Karte des Kunden fehlgeschlagen ist und die nächste Erneuerung den Zugriff neu gewährt. Ein manual oder subscription_cancelled Widerruf ist beabsichtigt. Behandeln Sie sie in der Kundenkommunikation unterschiedlich.id der Gewährung als Ihre Idempotenzschlüssel. Eine einzelne Gewährung löst maximal ein created Ereignis, ein Terminalereignis (delivered oder failed) und ein revoked Ereignis aus. Wiederholungen aus dem Webhook-System können Ereignisse wiederholen; entdoppeln Sie anhand der Gewährung id plus type.license_key und digital_product_delivery, um den Integrationstyp zu erkennen. Die Nutzlast der Gewährung selbst trägt nicht den Integrationstyp, aber genau eines dieser verschachtelten Objekte wird für Lizenzschlüssel- und digitale Datei-Berechtigungen ausgefüllt.oauth_url dem Kunden an. Das entitlement_grant.created Ereignis für Discord-, GitHub- oder Notion-Abonnentenflüsse enthält ein oauth_url und oauth_expires_at. Senden Sie es per E-Mail an den Kunden oder zeigen Sie es in Ihrer App an, um die Lieferung zu ermöglichen.Detailed view of a single entitlement grant: who it's for, its lifecycle state, and any integration-specific delivery payload.
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.
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.
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.