Skip to main content
Feature flag entitlement により、Dodo Payments は billing-aware な feature flag store になります。advanced_reports のような flag を product に紐付けると、支払いを行ったすべての customer に grant が付与され、アプリケーションは API 経由で確認するか、webhooks と同期できます。外部 platform、OAuth step、delivery step は不要です。grant 自体が capability になります。

配信されるもの

Dodo Payments の外部に送信されるものはありません。grant 自体が deliverable です。
  • 購入時、Dodo Payments は Delivered に grant を直接作成します。Pending に入ることはなく、customer の操作も不要で、失敗する可能性のある delivery step もありません。
  • grant には型付きの feature payload が含まれます: { "feature_type": "boolean", "feature_id": "advanced_reports" }。アプリケーションは feature_id を読み取り、unlock する機能を決定します。
  • Cancellation、refund、または手動の revoke により、grant は Revoked に移行し、customer に配信された grant から flag が消えます。
よくある使用例として、プランに基づく機能制御(プロが分析を解除)、アドオン機能(“APIアクセス”のアップグレード)、一度限りの購入として販売されるアーリーアクセスプログラムがあります。
feature_id は選択した identifier であり、entitlements 間で unique ではありません。たとえば、同じ feature_id を付与する monthly の Pro plan と yearly の Pro plan のように、2 つの entitlements が同じ feature_id を付与できます。

Feature Flag の作成

1

Open Entitlements

Dodo Payments dashboard で Entitlements に移動し、+ をクリックして新しい entitlement の作成を開始し、Feature Flags を選択します。
2

Name the Flag

dashboard と reports に表示する Display Name と、flag が制御する内容をチームが把握できるように Description を入力します。Feature ID はアプリケーションが確認する値です。dashboard では display name から自動入力されます(たとえば、“API access” は api_access になります)が、編集もできます。スペースは使用できません。
表示名、機能ID、説明、メタデータのキー-バリューエントリを備えた新しい機能フラグフォーム

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

3

Add Metadata (Optional)

Meta Data をオンにすると、limits、tier names、quotas などの key-value configuration を flag とともにアプリケーションへ渡せます。各ペアについて Add Entry をクリックします。metadata で limits を紐付ける を参照してください。
4

Confirm

確認をクリックします。フラグが認可リストに表示され、製品に付属する準備が整います。
付与活動パネルを備えたAdvanced Reports機能フラグを示す認可ダッシュボード

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

Product への紐付け

product を開くか作成し、Entitlements card を見つけます。+ をクリックして既存の entitlements を紐付け、feature flag を選択して Done をクリックします。
Advanced Reports機能フラグが選択された認可アタッチパネル

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

アタッチされたフラグは製品フォームに表示され、チェックアウトプレビューには含まれているとしてリストされます。
EntitlementsカードにAdvanced Reports機能フラグがアタッチされた製品フォーム

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

必須 Configuration

Create via API


Metadata で Limits を紐付ける

boolean flag は「この customer がこの feature を持っているか」を答えます。Metadata は「どのような configuration で持っているか」を答えます。Entitlement metadata は string、integer、number、boolean の値を受け入れます。各 grant には、grant 作成時点の entitlement の metadata の frozen snapshot が保存されます。 この snapshot により、metadata を plan limits に安全に使用できます。
  • 後から entitlement の metadata を編集しても影響するのは future の grant のみです。customer は購入時の limits を維持します。
  • 各 grant は metadata field に snapshot を返すため、1 回の API call で flag とその configuration の両方を取得できます。
たとえば、{ "tier": "pro", "monthly_report_limit": 100 } を持つ advanced_reports flag を使用すると、アプリケーションは dashboard を unlock し、追加の lookup なしで 100-report quota も適用できます。後から limit を 250 に引き上げても、既存の customer は新しい grant(たとえば plan change 後)を受け取るまで 100 のままです。
limits と configuration には metadata を使用し、feature_id は identity のみに使用してください。ID に limit(advanced_reports_100)を埋め込むと、limit が変更されるたびに新しい flag が必要になり、アプリケーションの checks が壊れます。

Customer の Features を確認する

customer が持つ features の set を構築するには、配信済みの feature flag grants を一覧表示します。endpoint はすべての entitlements にまたがる grant ごとに 1 行を返し、integration_type と status で filter できます。これらの examples では、Create via API の client を使用しています。
feature payload は feature_flag grants にのみ設定されます。それ以外の integration type ではすべて null です。完全な response shape については、List Customer Grants API reference を参照してください。
すべての request で API を呼び出すと、hot path に latency が追加されます。各 customer の feature set を短い TTL(hours ではなく minutes)で cache し、grant の state が変化したときは webhook handler から cache を invalidate してください。これにより checks を高速に保ち、次の request で revoke を反映できます。

Lifecycle

Feature flag grants は標準の grant lifecycle に従いますが、delivery step がないという簡略化があります。そのため、grant が Pending に留まることも、Failed に移行することもありません。 Grants は entitlement と customer ごとに idempotent です。customer が flag の revoke されていない grant を保持している間は、再購入や renewal によって duplicate が作成されることはありません。

Webhooks

polling の代わりに flag を独自の database に反映するには、entitlement_grant.* events を subscribe します。
  • entitlement_grant.created は、Delivered の状態で、feature payload とともに届きます。feature を有効にします。
  • entitlement_grant.delivered は、以前に revoked された grant が復元されたときに発生します。feature を再度有効にします。
  • entitlement_grant.revoked は access が取り消されたことを示します。feature を無効にし、メッセージを決定するために revocation_reason を確認します。
この Express handler は SDK で webhook signature を検証し、flag state を保存します。
TypeScript
Feature flags で entitlement_grant.failed が発生することはありません。delivery は Dodo Payments 内で完全に処理されるためです。

Example: Pro Plan で Advanced Reports を Unlock する

  1. flag を作成します。 feature_id: advanced_reports を設定し、{ "tier": "pro", "monthly_report_limit": 100 } の metadata を追加します。
  2. 紐付けます。 Pro Plan subscription product に紐付けます。
  3. customer が subscribe します。 Dodo Payments は Delivered grant を作成し、entitlement_grant.created を発火します。webhook handler は customer に対して advanced_reports を有効にし、limit を 100 に設定します。
  4. アプリが feature を gate します。 dashboard の load 時に cached feature set を確認するか listEntitlementGrants を呼び出し、advanced_reports が存在する場合にのみ reports tab を render します。
  5. customer がキャンセルします。 Dodo Payments は grant を revoke して entitlement_grant.revoked を発火し、handler は feature を無効にします。subscription が後から dunning によって回復すると、entitlement_grant.delivered が feature を復元します。コード変更は必要ありません。

Best Practices

  • snake_case では stable な feature IDs を使用します。 アプリケーション code はこれらの strings を確認するため、名前の変更は双方にとって breaking change になります。
  • capability ごとに 1 つの flag を使用します。 1 つの pro_bundle よりも、advanced_reports と api_access を 2 つの entitlements として使用することを推奨します。これにより revoke と plan combinations を適切に管理できます。
  • webhooks を state の source とし、API で検証します。 Webhooks により database を最新に保てます。list endpoint は reconciliation jobs と cache misses における source of truth です。
  • Revoked を immediate として扱います。 revoked flag は、customer がその feature の料金を支払わなくなったことを意味します。次の session ではなく、次の request で gate してください。
  • limits は code ではなく metadata に設定します。 quota の変更は entitlement の編集だけで済みます。新しい customer には新しい値が適用され、既存の grants には購入時の snapshot が維持されます。
最終更新日 2026年9月26日