Skip to main content
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, o grant é criado e passa diretamente para Delivered. Não há uma fase Pending, nenhuma ação do cliente e nenhuma possibilidade de falha na entrega.
  • O grant contém um payload tipado feature: { "feature_type": "boolean", "feature_id": "advanced_reports" }. Sua aplicação lê feature_id para decidir o que desbloquear.
  • O cancelamento, reembolso ou revogação manual move o grant para Revoked, e sua aplicação vê a flag desaparecer.
Usos comuns incluem feature gating baseado em plano (Pro desbloqueia analytics), capacidades adicionais (um upgrade de “acesso à API”), e programas de acesso antecipado vendidos como compras únicas.
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

1

Open Entitlements

No seu painel do Dodo Payments, vá para Entitlements e clique em + para iniciar um novo entitlement, depois escolha Feature Flags.
2

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.
Novo formulário de Feature Flag com nome de exibição, ID de recurso, descrição e entradas de metadados chave-valor

Creating a feature flag. The Feature ID is what your application checks; Meta Data attaches limits alongside the flag.

3

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.
4

Confirm

Clique em Confirmar. A flag aparece na sua lista de entitlements, pronta para ser anexada aos produtos.
Painel de Entitlements mostrando a feature flag de Advanced Reports com seu painel de atividades de concessão

The created feature flag. The right pane tracks every customer grant issued from it.

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.
Painel de anexação de Entitlements com a feature flag de Advanced Reports selecionada

Attaching the feature flag to a product. One product can deliver multiple entitlements.

A flag anexada aparece no formulário do produto, e a visualização da finalização da compra a lista em Inclui.
Formulário de produto com a feature flag de Advanced Reports anexada no cartão de Entitlements

The product now includes the feature flag. Every successful purchase or active subscription grants it.

Configuração obrigatória

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.
Por exemplo, uma flag 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).
Use metadados para limites e configuração; use feature_id apenas para identidade. Codificar limites no id (advanced_reports_100) força uma nova flag para cada mudança de limite e quebra as verificações da sua aplicação.

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 por integration_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.
Verificar a API em cada solicitação adiciona latência ao seu caminho quente. Armazene em cache o conjunto de funcionalidades por cliente com um TTL curto (minutos, não horas), e invalide o cache do seu manipulador de webhook quando uma concessão mudar de estado — essa combinação mantém as verificações rápidas e as revogações quase instantâneas.

Ciclo de vida

Os grants de feature flag seguem o ciclo de vida padrão de um grant com uma simplificação: não há uma etapa de entrega, portanto os grants nunca permanecem em Pending nem avançam para Failed. As concessões são idempotentes por entitlement e cliente: enquanto um cliente tiver uma concessão não revogada para uma flag, compras repetidas e renovações não criam duplicatas.

Webhooks

Assine os eventos entitlement_grant.* para espelhar flags no seu próprio banco de dados em vez de fazer polling:
  • entitlement_grant.created — já chega em Delivered com o payload feature. Ative a feature.
  • entitlement_grant.delivered — é acionado quando um grant anteriormente revogado é restaurado. Reative a feature.
  • entitlement_grant.revoked — acesso retirado. Desative a feature e verifique revocation_reason para decidir sua mensagem.
TypeScript
Não há 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

  1. Crie a flag. feature_id: advanced_reports com os metadados { "tier": "pro", "monthly_report_limit": 100 }.
  2. Associe-a ao produto de assinatura Pro Plan.
  3. Um cliente assina. Dodo Payments cria um grant Delivered e aciona entitlement_grant.created; seu webhook handler ativa advanced_reports para o cliente com um limite de 100.
  4. Seu app controla o acesso à feature. Ao carregar o dashboard, verifique o conjunto de features em cache (ou chame listEntitlementGrants) e renderize a aba de relatórios somente quando advanced_reports estiver presente.
  5. O cliente cancela. Dodo Payments revoga o grant e aciona entitlement_grant.revoked; seu handler desativa a feature. Se o cliente se recuperar posteriormente por meio de dunning, entitlement_grant.delivered a restaura — nenhuma alteração de código é necessária.

Melhores práticas

  • Use IDs de feature estáveis em snake_case. O código da sua aplicação verifica essas strings; renomear uma delas é uma alteração incompatível em ambos os lados.
  • Uma flag por capacidade. Prefira advanced_reports + api_access como dois entitlements em vez de um único pro_bundle — a revogação e as combinações de planos permanecem organizadas.
  • Use webhooks para controlar o estado e verifique com a API. Webhooks mantêm seu banco de dados atualizado; o endpoint de listagem é a fonte de verdade para jobs de reconciliação e falhas de cache.
  • Trate Revoked como imediato. Uma flag revogada significa que o cliente não está mais pagando pela feature. Controle o acesso na próxima requisição, não na próxima sessão.
  • Coloque os limites nos metadados, não no código. Alterar uma quota exige apenas editar o entitlement — novos clientes a recebem automaticamente, enquanto os grants existentes mantêm o snapshot adquirido.
Última modificação em 6 de agosto de 2026