Um entitlement de feature flag transforma o Dodo Payments em um armazenamento de flags de recurso ciente de faturamento. Anexe uma flag como
advanced_reports a um produto, e todo cliente pagante recebe uma concessão que sua aplicação pode verificar via API ou manter sincronizado com webhooks. Nenhuma plataforma externa, sem OAuth, sem etapa de entrega — a própria concessão é a capacidade.O que é entregue
Nada sai do Dodo Payments — a concessão é a entrega:- Na compra, a concessão é criada e move-se diretamente para
delivered. Não há fasepending, nenhuma ação do cliente, e nenhuma possibilidade de falha na entrega. - A concessão carrega um payload digitado
feature:{ "feature_type": "boolean", "feature_id": "advanced_reports" }. Sua aplicação lêfeature_idpara decidir o que desbloquear. - Cancelamento, reembolso, ou revogação manual movem a concessão para
revoked, e sua aplicação vê a flag desaparecer.
feature_id é um identificador escolhido pelo comerciante, não único entre os entitlements. Dois entitlements podem conferir o mesmo feature_id — por exemplo, um plano Pro mensal e anual ambos concedendo advanced_reports.Criar uma feature flag
Open Entitlements
No seu painel do Dodo Payments, vá para Entitlements e clique em + para iniciar um novo entitlement, depois escolha Feature Flags.
Name the flag
Dê à flag um Nome de Exibição para seu painel, um ID de Recurso que sua aplicação irá verificar (o painel sugere um a partir do nome), e uma Descrição para que sua equipe saiba o que controla.

Optionally add metadata
Alternar Meta Data para anexar configuração chave-valor — limites, nomes de níveis, cotas — que é entregue à sua aplicação junto com a flag. Veja Anexar limites com metadados.
Anexar a um produto
Abra um produto (ou crie um), encontre o cartão Entitlements, e clique em + para anexar entitlements existentes. Selecione sua feature flag e clique em Concluir.

Configuração obrigatória
| Campo | Obrigatório | Descrição |
|---|---|---|
feature_id | Sim | Identificador que sua aplicação verifica, por exemplo, advanced_reports. Não único entre os entitlements. |
feature_type | Sim | Tipo de capacidade conferida. Apenas boolean é suportado hoje. |
Criar via API
Anexar limites com metadados
Uma flag booleana responde “este cliente possui o recurso?”. Os metadados respondem “com qual configuração?”. Os metadados de entitlement aceitam valores de string, inteiro, número e booleano, e cada concessão toma um instantâneo congelado dos metadados do entitlement no momento em que é criada. Esse comportamento de instantâneo é o que torna os metadados seguros para usar em limites de plano:- Editar os metadados do entitlement posteriormente afeta apenas as concessões futuras. Os clientes mantêm os limites sob os quais foram comprados.
- O instantâneo é retornado em cada concessão como seu campo
metadata, então uma chamada API fornece tanto a flag quanto sua configuração.
advanced_reports com { "tier": "pro", "monthly_report_limit": 100 } permite que sua aplicação desbloqueie o dashboard e imponha a cota de 100 relatórios sem uma segunda consulta. Se mais tarde você aumentar o limite para 250, os clientes existentes permanecem em 100 até receberem uma nova concessão (por exemplo, após uma mudança de plano).
Verificar recursos de um cliente
Liste concessões de feature-flag entregues a um cliente e construa o conjunto de recursos habilitados. O endpoint retorna uma linha por concessão em todos os entitlements, filtrável porintegration_type e status.
O payload
feature é populado apenas nas concessões feature_flag; ele é null para todos os outros tipos de integração. Veja a referência de API List Customer Grants para a forma completa da resposta.Ciclo de vida
As concessões de feature flag seguem o ciclo de vida padrão da concessão com uma simplificação: não há etapa de entrega, então as concessões nunca se encontram empending e nunca se movem para failed.
| Acionador | Efeito |
|---|---|
| Pagamento único bem-sucedido / assinatura torna-se ativa | Concessão criada com status: delivered e delivered_at definidos. |
| Assinatura em espera, cancelada ou expirada | Concessão revogada com revocation_reason correspondente. |
| Reembolso em um pagamento único | Concessão revogada com revocation_reason: refund. |
| Assinatura recupera (por exemplo, cobrança bem-sucedida) | A concessão revogada é restaurada para delivered — mesma concessão id, campos de revogação limpos. |
| Revogação manual via API | Concessão revogada com revocation_reason: manual. Não é restaurada automaticamente na renovação. |
Webhooks
Assine os eventosentitlement_grant.* para espelhar flags no seu próprio banco de dados em vez de fazer polling:
entitlement_grant.created— chega jádeliveredcom o payloadfeature. Habilite o recurso.entitlement_grant.delivered— dispara quando uma concessão anteriormente revogada é restaurada. Re-habilite o recurso.entitlement_grant.revoked— acesso retirado. Desabilite o recurso e verifiquerevocation_reasonpara decidir sua mensagem.
TypeScript
entitlement_grant.failed para feature flags — a entrega acontece inteiramente dentro do Dodo Payments e não pode falhar.
Exemplo: Plano Pro desbloqueia relatórios avançados
- Crie a flag.
feature_id: advanced_reportscom metadados{ "tier": "pro", "monthly_report_limit": 100 }. - Anexe-a ao seu produto de assinatura Pro Plan.
- Um cliente se inscreve. O Dodo Payments cria uma concessão
deliverede disparaentitlement_grant.created; seu manipulador de webhook habilitaadvanced_reportspara o cliente com um limite de 100. - Sua aplicação bloqueia o recurso. Ao carregar o dashboard, verifique o conjunto de funcionalidades em cache (ou chame
listEntitlementGrants) e exiba a aba de relatórios apenas quandoadvanced_reportsestiver presente. - O cliente cancela. O Dodo Payments revoga a concessão e dispara
entitlement_grant.revoked; seu manipulador desabilita o recurso. Se o cliente se recuperar posteriormente por meio de dunning,entitlement_grant.deliveredo restaura — nenhuma alteração de código necessária.
Melhores práticas
- Use ids de recursos estáveis e em snake_case. O código da sua aplicação verifica essas strings; renomear uma é uma mudança quebradora em ambos os lados.
- Uma flag por capacidade. Prefira
advanced_reports+api_accesscomo dois entitlements ao invés de um únicopro_bundle— a revogação e as misturas de planos permanecem limpas. - Dirija o estado a partir de webhooks, verifique com a API. Webhooks mantêm seu banco de dados atualizado; o endpoint de lista é a fonte de verdade para trabalhos de reconciliação e falhas de cache.
- Trate
revokedcomo imediato. Uma flag revogada significa que o cliente não está mais pagando pelo recurso. Bloqueie na próxima solicitação, não na próxima sessão. - Coloque limites em metadados, não em código. Alterar uma cota só requer editar o entitlement — novos clientes a capturam automaticamente enquanto concessões existentes mantêm seu instantâneo comprado.
