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 Gewährungszeile wurde gerade eingefügt. Die Gewährung hat ab diesem Zeitpunkt immer einen stabilenid, 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 bleibtPending, 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 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 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).
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)
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. Einpayment.succeededEreignis sagt Ihnen, dass das Geld eingegangen ist; es sagt Ihnen nicht, dass der Kunde das GitHub-Repo oder die Discord-Rolle bereits hat. DasdeliveredEreignis ist die maßgebliche Quelle für die Erfüllung. - Ordnen Sie
revocation_reasonRetentionsflüssen zu. Einsubscription_on_holdWiderruf bedeutet normalerweise, dass die Karte des Kunden fehlgeschlagen ist und die nächste Erneuerung den Zugriff neu gewährt. Einmanualodersubscription_cancelledWiderruf ist beabsichtigt. Behandeln Sie sie in der Kundenkommunikation unterschiedlich. - Verwenden Sie die
idder Gewährung als Ihre Idempotenzschlüssel. Eine einzelne Gewährung löst maximal eincreatedEreignis, ein Terminalereignis (deliveredoderfailed) und einrevokedEreignis aus. Wiederholungen aus dem Webhook-System können Ereignisse wiederholen; entdoppeln Sie anhand der Gewährungidplustype. - Untersuchen Sie
license_keyunddigital_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_urldem Kunden an. Dasentitlement_grant.createdEreignis für Discord-, GitHub- oder Notion-Abonnentenflüsse enthält einoauth_urlundoauth_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 Ereignispayment.succeededteilt 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 Ereignisdeliveredist die maßgebliche Quelle für die Erfüllung. - Ordne
revocation_reasonden Retention-Abläufen zu. Ein Widerrufsubscription_on_holdbedeutet normalerweise, dass die Karte des Kunden fehlgeschlagen ist und der Zugriff bei der nächsten Verlängerung erneut gewährt wird. Ein Widerrufmanualodersubscription_cancelledist beabsichtigt. Berücksichtige diesen Unterschied in der Kundenkommunikation. - Verwende
iddes Grants als Idempotency Key. Ein einzelner Grant erzeugt höchstens ein Ereigniscreated, höchstens ein abschließendes Ereignis (deliveredoderfailed) und höchstens ein Ereignisrevoked. Erneute Zustellungen durch das Webhook-System können Ereignisse wiederholen. Entferne Duplikate anhand voniddes Grants undtype. - Lies
integration_type, um den Grant-Typ zu erkennen. Die Payload enthältintegration_typedirekt (zum Beispiellicense_key,digital_files,discord). Die verschachtelten Objektelicense_keyunddigital_product_deliverywerden ausgefüllt, sobald die entsprechenden Grants zugestellt wurden. Ein manuell erfüllter License-Key-Grant bleibtPendingmitintegration_type: "license_key"und einemnulllicense_key, bis du ihn erfüllst. - Stelle bei OAuth-basierten Grants
oauth_urldem Kunden bereit. Das Ereignisentitlement_grant.createdfür Discord-, GitHub- oder Notion-Abonnenten-Flows enthältoauth_urlundoauth_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 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.