Skip to main content

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. Alle vier Ereignisse teilen sich die gleiche EntitlementGrantResponse Nutzlast, die im untenstehenden Schema dokumentiert ist.

Ereignisauslöser

entitlement_grant.created

Eine Gewährungszeile wurde gerade eingefügt. Die Gewährung hat ab diesem Zeitpunkt immer einen stabilen 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-basierte Integrationen (Discord, GitHub, Notion) enthalten ein oauth_url, das der Kunde besuchen muss, um die Zustimmung abzuschließen. Die Gewährung bleibt pending, bis der Kunde autorisiert.
  • Plattform-direkte Integrationen (Telegram, Framer, Digitale Dateien) bleiben nur kurzzeitig pending, während der Plattformaufruf läuft, und wechseln dann zu delivered.

entitlement_grant.delivered

Die Gewährung ist von 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.

entitlement_grant.failed

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).
Behandeln Sie entitlement_grant.failed als umsetzbar. Der Kunde hat bezahlt, aber keinen Zugriff erhalten. Leiten Sie Misserfolge an Ihr Support-Team weiter oder lösen Sie eine Neuerteilung aus, sobald das zugrunde liegende Problem gelöst ist.

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. Das revocation_reason Feld zeichnet den Auslöser auf.

Nutzlastvarianten

Das 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.
Für alle anderen Integrationstypen (Discord, GitHub, Telegram, Framer, Notion) sind beide Felder null; die relevante Konfiguration wird in der Berechtigung selbst erfasst, nicht in der Gewährung.

Beispiel-Nutzlasten

Lizenzschlüssel geliefert (entitlement_grant.delivered)

Digitale Dateien geliefert (entitlement_grant.delivered)

Discord-Rolle erstellt und ausstehend (entitlement_grant.created)

Gewährung bei Abonnementstornierung widerrufen (entitlement_grant.revoked)

Lieferung fehlgeschlagen (entitlement_grant.failed)


Integrationstipps

  • Warten Sie auf 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.
  • Ordnen Sie 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.
  • Verwenden Sie die 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.
  • Untersuchen Sie 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.
  • Für OAuth-basierte Gewährungen, zeigen Sie 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.

Integrationstipps

  • Warte auf entitlement_grant.delivered, bevor du davon abhängige Funktionen freischaltest. Ein payment.succeeded-Ereignis zeigt dir, dass die Zahlung abgewickelt wurde; es bedeutet nicht, dass der Kunde bereits Zugriff auf das GitHub-Repository oder die Discord-Rolle hat. Das delivered-Ereignis ist die maßgebliche Quelle für die Bereitstellung.
  • Ordne revocation_reason den Retention-Abläufen zu. Ein subscription_on_hold-Entzug bedeutet normalerweise, dass die Karte des Kunden fehlgeschlagen ist und der Zugriff bei der nächsten Verlängerung erneut gewährt wird. Ein manual- oder subscription_cancelled-Entzug ist beabsichtigt. Behandle diese Fälle in der Kundenkommunikation unterschiedlich.
  • Verwende den Grant id als Idempotency Key. Ein einzelner Grant löst höchstens ein created-Ereignis, höchstens ein abschließendes Ereignis (delivered oder failed) und höchstens ein revoked-Ereignis aus. Erneute Zustellungen durch das Webhook-System können Ereignisse wiederholen; entferne Duplikate anhand des Grants id und type.
  • Lies integration_type aus, um den Grant-Typ zu erkennen. Die Payload enthält integration_type direkt (zum Beispiel license_key, digital_files, discord). Die verschachtelten Objekte license_key und digital_product_delivery werden ausgefüllt, sobald die jeweiligen Grants bereitgestellt wurden; ein manuell erfüllter License-Key-Grant bleibt pending mit integration_type: "license_key" und einem null license_key, bis du ihn erfüllst.
  • Bei OAuth-basierten Grants solltest du oauth_url dem Kunden anzeigen. Das entitlement_grant.created-Ereignis für Subscriber-Abläufe von Discord, GitHub oder Notion enthält ein oauth_url und oauth_expires_at. Sende es per E-Mail an den Kunden oder zeige es in deiner App an, um die Bereitstellung 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
string
erforderlich

Brand id this grant belongs to.

business_id
string
erforderlich

Identifier of the business that owns the grant.

created_at
string<date-time>
erforderlich

Timestamp when the grant was created.

customer_id
string
erforderlich

Identifier of the customer the grant was issued to.

entitlement_id
string
erforderlich

Identifier of the entitlement this grant was issued from.

id
string
erforderlich

Unique identifier of the grant.

integration_type
enum<string>
erforderlich

The integration type of the grant's entitlement (e.g. license_key).

Verfügbare Optionen:
discord,
telegram,
github,
figma,
framer,
notion,
digital_files,
license_key,
feature_flag
metadata
Metadata · object
erforderlich

Arbitrary key-value metadata recorded on the grant.

status
enum<string>
erforderlich

Lifecycle status of the grant.

Verfügbare Optionen:
Pending,
Delivered,
Failed,
Revoked
updated_at
string<date-time>
erforderlich

Timestamp when the grant was last modified.

delivered_at
string<date-time> | null

Timestamp when the grant transitioned to delivered, when applicable.

digital_product_delivery
null | Digital Product Delivery · object

Digital-product-delivery payload, present when the entitlement integration is digital_files.

error_code
string | null

Machine-readable code reported when delivery failed, when applicable.

error_message
string | null

Human-readable message reported when delivery failed, when applicable.

feature
null | object

Typed feature payload, present only when the entitlement integration is feature_flag; null for every other integration type.

license_key
null | object

License-key delivery payload, present when the entitlement integration is license_key.

oauth_expires_at
string<date-time> | null

Timestamp when oauth_url stops being valid, when applicable.

oauth_url
string | null

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.

payment_id
string | null

Identifier of the payment that triggered this grant, when applicable.

revocation_reason
string | null

Reason recorded when the grant was revoked, when applicable.

revoked_at
string<date-time> | null

Timestamp when the grant transitioned to revoked, when applicable.

subscription_id
string | null

Identifier of the subscription that triggered this grant, when applicable.

Zuletzt geändert am 31. Juli 2026