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. Bei automatisch erfüllten Lizenzschlüsseln wird die Zeile direkt mit ausgefüllten Feldern status: "Delivered" und delivered_at eingefügt. Daher folgt auf ein einzelnes Ereignis created keine weitere Statusänderung, 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) enthalten ein oauth_url, das der Kunde aufrufen muss, um die Zustimmung abzuschließen. Der Grant bleibt Pending, bis der Kunde autorisiert.
  • Direkte Plattformintegrationen (Telegram, Framer, Digital Files) bleiben nur kurz in Pending, während der Plattformaufruf ausgeführt wird, und wechseln anschließend zu 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. Der Grant ist von Pending zu Delivered gewechselt. Der Kunde hat nun den im Entitlement beschriebenen Zugriff. Verwende dieses Ereignis, 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 enthält den Zeitpunkt, zu dem die Zustellung abgeschlossen wurde. Bei Grants, die bereits bei der Erstellung Delivered waren, erhältst du die Ereignisse created und delivered direkt nacheinander. 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: 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_key ist enthalten, wenn integration_type license_key entspricht 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 noch Pending ist, lautet dieses Objekt null, bis du den Grant erfüllst.
  • digital_product_delivery ist enthalten, wenn integration_type digital_files entspricht. Es enthält vorab signierte Download-URLs, das optionale instructions und das optionale external_url.
  • feature ist enthalten, wenn integration_type feature_flag entspricht. Es enthält feature_type und feature_id der durch den Grant gewährten Funktionalität.
Bei allen anderen Integrationstypen (Discord, GitHub, Telegram, Figma, Framer, Notion) lauten diese verschachtelten Felder null. Die relevante Konfiguration ist im Entitlement selbst und nicht im Grant enthalten.

Beispiel-Nutzlasten

Lizenzschlüssel geliefert (entitlement_grant.delivered)

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.

Gewährung bei Abonnementstornierung widerrufen (entitlement_grant.revoked)

Lieferung fehlgeschlagen (entitlement_grant.failed)


  • 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 abhängige Funktionen freischaltest. Ein Ereignis payment.succeeded teilt dir mit, dass die Zahlung erfolgreich abgeschlossen wurde; es bedeutet nicht, dass der Kunde bereits Zugriff auf das GitHub-Repository oder die Discord-Rolle hat. Das Ereignis delivered ist die maßgebliche Quelle für die Erfüllung.
  • Ordne revocation_reason den Retention-Abläufen zu. Ein Widerruf subscription_on_hold bedeutet normalerweise, dass die Karte des Kunden fehlgeschlagen ist und der Zugriff bei der nächsten Verlängerung erneut gewährt wird. Ein Widerruf manual oder subscription_cancelled ist beabsichtigt. Berücksichtige diesen Unterschied in der Kundenkommunikation.
  • Verwende id des Grants als Idempotency Key. Ein einzelner Grant erzeugt höchstens ein Ereignis created, höchstens ein abschließendes Ereignis (delivered oder failed) und höchstens ein Ereignis revoked. Erneute Zustellungen durch das Webhook-System können Ereignisse wiederholen. Entferne Duplikate anhand von id des Grants und type.
  • Lies integration_type, 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 entsprechenden Grants zugestellt 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.
  • Stelle bei OAuth-basierten Grants oauth_url dem Kunden bereit. Das Ereignis entitlement_grant.created für Discord-, GitHub- oder Notion-Abonnenten-Flows enthält oauth_url und oauth_expires_at. Sende es dem Kunden per E-Mail oder zeige es 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
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 21. August 2026