Skip to main content
機能フラグの認可により、Dodo Paymentsを請求対応の機能フラグストアに変えることができます。advanced_reportsのようなフラグを製品に付けると、支払済みの顧客全員に付与が行われ、APIを通じてチェックしたり、Webhookで同期を維持したりできます。外部プラットフォームやOAuth、配信ステップは不要で、付与そのものが機能です。

What gets delivered

Dodo Paymentsからは何も離れません。付与が成果物です:
  • 購入時に付与が作成され、即座にdeliveredに移行します。pendingフェーズはなく、顧客の行動も不要で、配信が失敗することはありません。
  • 付与には型指定されたfeatureペイロードが含まれます:{ "feature_type": "boolean", "feature_id": "advanced_reports" }。アプリケーションはfeature_idを読み込んでどの機能を解除するかを判断します。
  • キャンセル、払い戻し、または手動による取り消しは、付与をrevokedに移動させ、アプリケーションからフラグが消えることがわかります。
よくある使用例として、プランに基づく機能制御(プロが分析を解除)、アドオン機能(“APIアクセス”のアップグレード)、一度限りの購入として販売されるアーリーアクセスプログラムがあります。
feature_idは商人が選択した識別子で、認可全体にわたって一意ではありません。2つの認可が同じfeature_idを付与することがあります。たとえば、月次および年次のプロプランの両方がadvanced_reportsを付与する場合があります。

Create a feature flag

1

Open Entitlements

Dodo PaymentsダッシュボードでEntitlementsに移動し、**+**をクリックして新しい認可を開始し、Feature Flagsを選択します。
2

Name the flag

フラグにダッシュボード用の表示名、アプリケーションが確認する機能ID(ダッシュボードが名前から提案するもの)およびそれが制御する内容をチームに知らせる説明を設定します。
表示名、機能ID、説明、メタデータのキー-バリューエントリを備えた新しい機能フラグフォーム

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

3

Optionally add metadata

メタデータを切り替えて、フラグとともにアプリケーションに配信されるキー-バリュー設定(制限、ティエ名、クオータなど)をアタッチします。詳細はメタデータで制限を付けるを参照してください。
4

Confirm

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

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

Attach to a product

製品を開く(または作成する)、Entitlementsカードを見つけて**+**をクリックし、既存の認可をアタッチします。機能フラグを選択し、完了をクリックします。
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.

Required configuration

Create via API


Attach limits with metadata

ブールフラグは「この顧客がこの機能を持っていますか?」に答えます。メタデータは「どのような設定で?」に答えます。認可メタデータは文字列、整数、数値、ブール値を受け入れることができ、各認可は作成時に認可のメタデータの固定スナップショットを取得します。 このスナップショット動作がメタデータをプランの制限に利用する際の安全性を提供します:
  • 後に認可のメタデータを編集しても、将来の付与にのみ影響します。顧客は購入時の制限が維持されます。
  • スナップショットは各付与にそのmetadataフィールドとして返されるため、1回のAPIコールでフラグとその設定の両方を取得できます。
たとえば、advanced_reportsフラグと{ "tier": "pro", "monthly_report_limit": 100 }を持つ場合、アプリケーションはダッシュボードを解除し、100件のレポートクオータを強制することができます。後で制限を250に引き上げても、既存の顧客は100のままで、プランが変更されたときに新しい付与を受け取るまで変更されません。
制限や設定にメタデータを使用してください。feature_idはアイデンティティのみに使用します。識別子に制限をエンコードする(advanced_reports_100)は、制限変更のたびに新しいフラグを強制し、アプリケーションのチェックを壊します。

Check a customer’s features

顧客にデリバリーされた機能フラグの付与をリストアップして、利用可能な機能のセットを構築します。このエンドポイントはすべての認可にわたって、付与ごとに1行を返し、integration_typestatusでフィルタリング可能です。
featureペイロードはfeature_flag付与のみに入力されます。他のすべての統合タイプに対してはnullです。完全な応答形状については、List Customer Grants APIリファレンスを参照してください。
毎回のリクエストでAPIをチェックすると、ホットパスに遅延が生じます。顧客ごとの機能セットを短いTTLでキャッシュし(数分、数時間ではない)、付与の状態が変わるとWebhookハンドラからキャッシュを無効化します。この組み合わせで、チェックが速く、取り消しが即座に近くなります。

Lifecycle

機能フラグの付与は、付与のライフサイクルと同じ標準に従いますが、一つ簡素化されています:配信ステップがないため、付与はpendingに置かれることがなく、failedに移動することがありません。 付与は認可および顧客ごとに冪等性を持ちます:顧客がフラグの未取り消しの付与を持つ間は、リピート購入と更新は重複を作成しません。

Webhooks

entitlement_grant.*イベントを購読して、フラグをポーリングする代わりに自分のデータベースにミラーリングします:
  • entitlement_grant.createddeliveredとしてすでに到着しており、featureペイロード付きです。機能を有効にします。
  • entitlement_grant.delivered — 以前に取り消された付与が復元されたときに発火します。機能を再有効化します。
  • entitlement_grant.revoked — アクセスが取り消されました。機能を無効にし、メッセージングを決定するためにrevocation_reasonを確認します。
TypeScript
機能フラグに対してentitlement_grant.failedはありません — 配信は完全にDodo Payments内で行われ、失敗することはありません。

Example: Pro plan unlocks advanced reports

  1. フラグを作成します。 feature_id: advanced_reportsとメタデータ{ "tier": "pro", "monthly_report_limit": 100 }
  2. それをプロプランのサブスクリプション製品にアタッチします。
  3. 顧客がサブスクライブします。 Dodo Paymentsがdeliveredの付与を作成し、entitlement_grant.createdを発火します。Webhookハンドラが顧客のために100の制限でadvanced_reportsを有効にします。
  4. アプリが機能を制御します。 ダッシュボードのロード時にキャッシュされた機能セットを確認(またはlistEntitlementGrantsを呼び出して)、advanced_reportsが存在する場合のみレポートタブを表示します。
  5. 顧客がキャンセルします。 Dodo Paymentsが付与を取り消し、entitlement_grant.revokedを発火します。ハンドラが機能を無効にします。顧客が督促を介して後で回復すると、entitlement_grant.deliveredがそれを復元します — コードの変更は不要です。

Best practices

  • 安定したsnake_case機能IDを使用します。 アプリケーションコードはこれらの文字列をチェックします。名前を変更することは、両側での破壊的変更です。
  • 1つの機能につき1つのフラグ。 SINGLE_advanced_reports + api_accessを2つの認可として選択し、単一のpro_bundleとします。取り消しおよびプランの組み合わせがスムーズになります。
  • 状態をwebhooksで駆動し、APIで検証します。 Webhooksはデータベースを最新に保ちます。リストエンドポイントは、調整ジョブとキャッシュミスのための真実の源です。
  • revokedを即時とみなします。 取り消されたフラグは、顧客がもはやその機能に対して支払っていないことを意味します。次のリクエストで、次のセッションではなく制御します。
  • メタデータに制限を設定し、コードには設定しません。 クオータを変更する場合、それは認可の編集だけを必要とし、新しい顧客は自動的にそれを取り入れ、既存の付与は購入したスナップショットを維持します。
最終更新日 2026年7月9日