Rättighetsbeviljande
Den nyttolast som skickas till din webhook-endpoint när ett rättighetsbeviljande skapas, levereras, misslyckas eller återkallas.
Webhook-händelser för rättighetsbeviljande
Dessa händelser utlöses när en kunds rättighetsbeviljande ändrar tillstånd, till exempel när en licensnyckel genereras, en Discord-roll tilldelas, en nedladdningslänk tillhandahålls eller åtkomst återkallas. Prenumerera på dessa händelser för att hålla din applikation synkroniserad med vad varje kund kan komma åt.EntitlementGrantResponse nyttolast dokumenterad i schemat nedan.
Händelsetriggare
entitlement_grant.created
En beviljanderad infogades just. Beviljandet har alltid en stabilid från och med nu, även om dess status ändras. Använd denna händelse för att registrera att uppfyllande pågår.
För licensnycklar infogas raden direkt med status: "delivered" och delivered_at ifyllda, så en enda created-händelse följs av inga ytterligare tillståndsändringar om inte beviljandet senare återkallas.
För alla andra integrationer anländer raden med status: "pending". En delivered eller failed-händelse följer när leveransen slutförs:
- OAuth-baserade integrationer (Discord, GitHub, Notion) inkluderar en
oauth_urlsom kunden måste besöka för att slutföra samtycket. Beviljandet förblirpendingtills kunden godkänner. - Plattformsdirekta integrationer (Telegram, Framer, Digitala Files) förblir i
pendingendast kort medan plattformsanropet körs, för att sedan flytta tilldelivered.
entitlement_grant.delivered
Beviljandet övergick frånpending till delivered. Kunden har nu åtkomsten som beskrivs av rättigheterna. Använd denna händelse för att låsa upp beroende funktioner i dina egna system, till exempel för att tillhandahålla en arbetsyta, skicka ett anpassat välkomstmail eller markera en “uppfylld” flagga.
Nyttolastens delivered_at-fält fångar när leveransen slutfördes. För beviljanden som anlände delivered vid skapandet, kommer du att få created och delivered-händelser back-to-back.
entitlement_grant.failed
Leverans försöktes och misslyckades med ett icke-återprovbart fel. Fältenerror_code och error_message förklarar felet. Vanliga orsaker inkluderar en återkallad OAuth-token, en nekad plattformsbehörighet eller ett saknat mål (t.ex., en raderad Discord-gille).
entitlement_grant.revoked
Åtkomst drogs tillbaka på plattformsnivån: Discord-roll borttagen, GitHub-samarbetare borttagen, licensnyckel inaktiverad, filnedladdnings-URL:er ej längre tillhandahållna. Fältetrevocation_reason registrerar utlösaren.
Nyttolastvarianter
Fältetdata är alltid ett EntitlementGrantResponse-objekt. Två integrationstyper bifogar extra kapslade objekt:
license_keyingår när rättighetsintegrationstypen ärlicense_key. Det innehåller den genererade nyckeln, utgångsdatum och aktiveringsanvändning.digital_product_deliveryingår när integrationstypen ärdigital_files. Det innehåller försignerade nedladdnings-URL:er, den valfriainstructions, och den valfriaexternal_url.
null; den relevanta konfigurationen fångas i själva rättigheten, inte i beviljandet.
Exempel på nyttolaster
Licensnyckel levererad (entitlement_grant.delivered)
Digitala filer levererade (entitlement_grant.delivered)
Discord-roll skapad och väntande (entitlement_grant.created)
Beviljande återkallat vid prenumerationsavslut (entitlement_grant.revoked)
Leverans misslyckades (entitlement_grant.failed)
Integrationstips
- Vänta på
entitlement_grant.deliveredinnan du låser upp beroende funktioner. Enpayment.succeededhändelse talar om för dig att pengarna gått igenom; det talar inte om för dig att kunden har GitHub-repot eller Discord-rollen än.delivered-händelsen är den sanningskälla för uppfyllande. - Kartlägg
revocation_reasontill retention flöden. Ensubscription_on_holdåterkallelse innebär vanligtvis att kundens kort misslyckades och nästa förnyelse kommer att nybevilja åtkomst. Enmanualellersubscription_cancelledåterkallelse är avsiktlig. Behandla dem olika i kundmeddelandena. - Använd grant
idsom din idempotensnyckel. Ett enda beviljande avger högst ettcreated-händelse och högst en slutlig händelse (deliveredellerfailed), och högst ettrevoked-händelse. Återleveranser från webhooksystemet kan upprepa händelser; dupplikat på grantidplustype. - Inspektera
license_keyochdigital_product_deliveryför att känna igen integrationstypen. Grant nyttolasten i sig bär inte integrationstypen, men exakt ett av dessa kapslade objekt fylls i för licensnyckel och digitala filer rättigheter. - För OAuth-baserade beviljanden, visa
oauth_urlför kunden.entitlement_grant.created-händelsen för Discord, GitHub, eller Notion prenumerantflöden inkluderar enoauth_urlochoauth_expires_at. Maila det till kunden eller visa det i din app för att låsa upp leveransen.
Integreringstips
- Vänta på
entitlement_grant.deliveredinnan du låser upp beroende funktioner. Enpayment.succeeded-händelse talar om att pengarna har gått igenom, men inte att kunden ännu har fått GitHub-repot eller Discord-rollen.delivered-händelsen är den tillförlitliga källan för fulfillment. - Koppla
revocation_reasontill retention-flöden. Ensubscription_on_holdrevoke innebär vanligtvis att kundens kort misslyckades och att nästa förnyelse ger åtkomst igen. Enmanual- ellersubscription_cancelled-revoke är avsiktlig. Hantera dem olika i kundkommunikationen. - Använd grant
idsom din idempotency key. En enda grant skickar högst encreated-händelse, högst en terminalhändelse (deliveredellerfailed) och högst enrevoked-händelse. Återleveranser från webhook-systemet kan upprepa händelser; deduplicera på grantidplustype. - Läs
integration_typeför att identifiera grant-typen. Payloaden innehållerintegration_typedirekt (till exempellicense_key,digital_files,discord). De kapslade objektenlicense_keyochdigital_product_deliveryfylls i när deras respektive grants har levererats; en manuellt uppfylld licensnyckel-grant förblirpendingmedintegration_type: "license_key"och ennulllicense_keytills du uppfyller den. - Visa
oauth_urlför kunden vid OAuth-baserade grants.entitlement_grant.created-händelsen för Discord-, GitHub- eller Notion-prenumerantflöden innehåller enoauth_urlochoauth_expires_at. Skicka den via e-post till kunden eller visa den i din app för att möjliggöra leveransen.
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.