Un diritto di feature flag trasforma Dodo Payments in un negozio di feature flag consapevole del billing. Associa un flag come
advanced_reports a un prodotto, e ogni cliente pagante ottiene un diritto che la tua applicazione può verificare tramite API o mantenere sincronizzato con webhooks. Nessuna piattaforma esterna, nessun OAuth, nessun passo di consegna — il diritto stesso è la capacità.Cosa viene consegnato
Nulla lascia Dodo Payments — il diritto è il deliverable:- Al momento dell’acquisto, il diritto viene creato e passa direttamente a
delivered. Non c’è nessuna fasepending, nessuna azione del cliente e nessun modo per il fallimento della consegna. - Il diritto porta un payload tipizzato
feature:{ "feature_type": "boolean", "feature_id": "advanced_reports" }. La tua applicazione leggefeature_idper decidere cosa sbloccare. - Cancellazione, rimborso o revoca manuale sposta il diritto a
revoked, e la tua applicazione vede il flag scomparire.
feature_id è un identificatore scelto dal merchant, non unico tra le entitlements. Due entitlements possono conferire lo stesso feature_id — ad esempio, un piano Pro mensile e annuale che entrambi concedono advanced_reports.Crea un feature flag
Open Entitlements
Nel tuo dashboard di Dodo Payments, vai a Entitlements e clicca + per iniziare un nuovo entitlement, quindi scegli Feature Flags.
Name the flag
Dai al flag un Display Name per il tuo dashboard, un Feature ID che la tua applicazione verificherà (il dashboard suggerisce uno dal nome), e una Description per far sapere al tuo team cosa controlla.

Optionally add metadata
Attiva Meta Data per allegare configurazioni chiave-valore — limiti, nomi di livelli, quote — che vengono consegnati alla tua applicazione insieme al flag. Vedi Allega limiti con metadati.
Associa a un prodotto
Apri un prodotto (o creane uno), trova la scheda Entitlements e clicca + per associare gli entitlements esistenti. Seleziona il tuo feature flag e clicca Fatto.

Configurazione richiesta
| Campo | Richiesto | Descrizione |
|---|---|---|
feature_id | Sì | Identificatore che la tua applicazione verifica, ad es. advanced_reports. Non unico tra le entitlements. |
feature_type | Sì | Tipo di capacità conferita. Solo boolean è supportato oggi. |
Creare via API
Allega limiti con metadati
Un flag booleano risponde “questo cliente ha la funzionalità?”. I metadati rispondono “con quale configurazione?”. I metadati di entitlement accettano valori stringa, intero, numero e booleano, e ogni diritto prende un istantanea congelata dei metadati di entitlement al momento della creazione. Quel comportamento dell’istantanea è ciò che rende sicuro l’uso dei metadati per i limiti di piano:- Modificare i metadati dell’entitlement in un secondo momento influisce solo sui futuri diritti. I clienti mantengono i limiti sotto i quali hanno acquistato.
- L’istantanea viene restituita su ogni diritto come suo campo
metadata, quindi una chiamata API ti dà sia il flag che la sua configurazione.
advanced_reports con { "tier": "pro", "monthly_report_limit": 100 } consente alla tua applicazione di sbloccare il dashboard e applicare il limite di 100 report senza una seconda ricerca. Se successivamente aumenti il limite a 250, i clienti esistenti rimangono a 100 fino a quando non ricevono un nuovo diritto (ad esempio, dopo un cambio di piano).
Verifica le funzionalità di un cliente
Elenca i diritti di feature flag consegnati a un cliente e costruisci l’insieme di caratteristiche abilitate. L’endpoint restituisce una riga per ogni diritto attraverso tutte le entitlements, filtrabile daintegration_type e status.
Il payload
feature è popolato solo su concessioni feature_flag; è null per ogni altro tipo di integrazione. Vedi il riferimento API List Customer Grants per la forma completa della risposta.Ciclo di vita
I diritti di feature flag seguono il ciclo di vita standard grant lifecycle con una semplificazione: non c’è nessun passo di consegna, quindi i diritti non siedono mai inpending e non si spostano mai a failed.
| Trigger | Effetto |
|---|---|
| Pagamento una tantum riuscito / abbonamento diventa attivo | Diritto creato con status: delivered e delivered_at impostati. |
| Abbonamento in pausa, cancellato o scaduto | Diritto revocato con il corrispondente revocation_reason. |
| Rimborso su un pagamento una tantum | Diritto revocato con revocation_reason: refund. |
| Abbonamento ripristinato (ad esempio, riscossione riuscita) | Il diritto revocato viene ripristinato a delivered — stesso diritto id, campi di revoca cancellati. |
| Revoca API manuale | Diritto revocato con revocation_reason: manual. Non viene ripristinato automaticamente al rinnovo. |
Webhooks
Iscriviti agli eventientitlement_grant.* per rispecchiare i flag nel tuo database invece di effettuare polling:
entitlement_grant.created— arriva giàdeliveredcon il payloadfeature. Abilita la funzionalità.entitlement_grant.delivered— si attiva quando un diritto precedentemente revocato viene ripristinato. Riabilita la funzionalità.entitlement_grant.revoked— accesso ritirato. Disabilita la funzionalità e controllarevocation_reasonper decidere il tuo messaggio.
TypeScript
entitlement_grant.failed per i feature flags — la consegna avviene interamente all’interno di Dodo Payments e non può fallire.
Esempio: Il piano Pro sblocca i report avanzati
- Crea il flag.
feature_id: advanced_reportscon metadati{ "tier": "pro", "monthly_report_limit": 100 }. - Associalo al prodotto di abbonamento del tuo Pro Plan.
- Un cliente si abbona. Dodo Payments crea un diritto
deliverede generaentitlement_grant.created; il tuo gestore webhook abilitaadvanced_reportsper il cliente con un limite di 100. - La tua app attiva la funzione. Al caricamento del dashboard, controlla l’insieme delle funzionalità memorizzato nella cache (o chiama
listEntitlementGrants) e visualizza la scheda dei report solo quandoadvanced_reportsè presente. - Il cliente cancella. Dodo Payments revoca il diritto e genera
entitlement_grant.revoked; il tuo gestore disabilita la funzione. Se il cliente in seguito si riprende tramite riscossione,entitlement_grant.deliveredla ripristina — nessuna modifica al codice necessaria.
Migliori pratiche
- Usa ID funzionalità stabili in snake_case. Il codice della tua applicazione controlla queste stringhe; rinominare uno è un cambiamento radicale su entrambi i lati.
- Un flag per capacità. Preferisci
advanced_reports+api_accesscome due entitlements su un singolopro_bundle— revoca e combinazioni di piani rimangono pulite. - Guida lo stato dai webhooks, verifica con l’API. I webhooks mantengono il tuo database aggiornato; l’endpoint della lista è la fonte della verità per i lavori di riconciliazione e gli eventi cache miss.
- Tratta
revokedcome immediato. Un flag revocato significa che il cliente non sta più pagando per la funzionalità. Attivalo alla prossima richiesta, non alla prossima sessione. - Metti i limiti nei metadati, non nel codice. Cambiare una quota richiede solo di modificare la entitlement — i nuovi clienti la acquisiscono automaticamente mentre i diritti esistenti mantengono la loro istantanea acquistata.
Best practices
- Use stable, snake_case feature ids. Your application code checks these strings; renaming one is a breaking change on both sides.
- One flag per capability. Prefer
advanced_reports+api_accessas two entitlements over a singlepro_bundle— revocation and plan mixes stay clean. - Drive state from webhooks, verify with the API. Webhooks keep your database current; the list endpoint is the source of truth for reconciliation jobs and cache misses.
- Treat
revokedas immediate. A revoked flag means the customer is no longer paying for the feature. Gate on the next request, not the next session. - Put limits in metadata, not in code. Changing a quota then only requires editing the entitlement — new customers pick it up automatically while existing grants keep their purchased snapshot.
