Skip to main content
Feature flag entitlement는 Dodo Payments를 결제 인식형 feature flag 저장소로 전환합니다. advanced_reports와 같은 flag를 제품에 연결하면 모든 결제 고객에게 grant가 부여되며, 애플리케이션은 API를 통해 이를 확인하거나 webhooks와 동기화할 수 있습니다. 외부 플랫폼, OAuth 단계 또는 delivery 단계가 필요하지 않습니다. grant 자체가 capability입니다.

제공되는 항목

Dodo Payments 외부로 전송되는 항목은 없습니다. grant 자체가 deliverable입니다:
  • 구매 시 Dodo Payments는 Delivered에 직접 grant를 생성합니다. Pending에 들어가지 않으며, 고객 작업이 필요하지 않고, 실패할 수 있는 delivery 단계도 없습니다.
  • grant에는 typed feature payload인 { "feature_type": "boolean", "feature_id": "advanced_reports" }가 포함됩니다. 애플리케이션은 feature_id를 읽어 어떤 기능을 잠금 해제할지 결정합니다.
  • 취소, 환불 또는 수동 revoke가 발생하면 grant는 Revoked로 이동하고, 고객의 delivered grants에서 flag가 사라집니다.
일반적인 사용 사례로는 플랜 기반 기능 게이팅(프로는 분석 기능 해제), 추가 기능(“API 액세스” 업그레이드), 일회성 구매로 판매되는 얼리 액세스 프로그램 등이 있습니다.
feature_id는 사용자가 선택하는 identifier이며 entitlement 간에 unique하지 않습니다. 예를 들어 동일한 feature_id를 부여하는 월간 Pro plan과 연간 Pro plan처럼 두 entitlement가 동일한 INLINE_CODE_PLACEHOLDER_8b4a4bef871fbab_END를 부여할 수 있습니다.

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를 켜면 애플리케이션이 flag와 함께 받는 key-value configuration을 연결할 수 있습니다. 예를 들면 limits, tier names 또는 quotas가 있습니다. 각 쌍마다 Add Entry를 클릭합니다. 메타데이터로 limits 연결을 참조하세요.
4

Confirm

확인을 클릭합니다. 플래그는 제품에 붙이기 위해 권한 목록에 나타납니다.
권한 대시보드에 권한 활동 창이 있는 고급 보고서 기능 플래그가 표시됨

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

Product에 연결

제품을 열거나 새로 만들고 Entitlements card를 찾습니다. **+**를 클릭하여 기존 entitlement를 연결하고 feature flag를 선택한 다음 Done을 클릭합니다.
자격 첨부 패널에 고급 보고서 기능 플래그 선택됨

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

첨부된 플래그는 제품 폼에 표시되고, 체크아웃 미리보기는 포함 아래에 이를 나열합니다.
권한 카드에 첨부된 고급 보고서 기능 플래그가 있는 제품 폼

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

필수 Configuration

API를 통한 생성


Metadata로 Limits 연결

boolean flag는 “이 고객에게 feature가 있는가?”라는 질문에 답합니다. Metadata는 “어떤 configuration으로 제공되는가?”에 답합니다. Entitlement metadata는 string, integer, number 및 boolean 값을 허용합니다. 모든 grant에는 grant가 생성될 때 entitlement metadata의 frozen snapshot이 포함됩니다. 이 snapshot 덕분에 metadata를 plan limits에 안전하게 사용할 수 있습니다:
  • 이후 entitlement의 metadata를 편집해도 future grants에만 영향을 줍니다. 고객은 구매 당시의 limits를 그대로 유지합니다.
  • 각 grant는 metadata field에 snapshot을 반환하므로 API call 한 번으로 flag와 configuration을 모두 가져올 수 있습니다.
예를 들어 { "tier": "pro", "monthly_report_limit": 100 }가 포함된 advanced_reports flag를 사용하면 애플리케이션이 dashboard를 잠금 해제하고 두 번째 lookup 없이 100-report quota도 적용할 수 있습니다. 이후 limit를 250으로 늘려도 기존 고객은 새 grant(예: plan change 후)를 받을 때까지 100을 유지합니다.
limits와 configuration에는 metadata를 사용하고, identity에는 feature_id만 사용하세요. ID에 limit를 인코딩하면( advanced_reports_100) limit가 변경될 때마다 새 flag가 필요해지고 애플리케이션의 checks가 중단됩니다.

Customer의 Features 확인

고객이 보유한 features 집합을 만들려면 delivered feature flag grants를 나열합니다. endpoint는 모든 entitlements에 걸쳐 grant당 한 row를 반환하며, integration_type 및 status로 필터링할 수 있습니다. 다음 예제에서는 Create via API의 client를 사용합니다.
feature payload는 feature_flag grants에만 채워집니다. 다른 모든 integration type에서는 null입니다. 전체 response shape는 List Customer Grants API reference를 참조하세요.
모든 request마다 API를 호출하면 hot path에 latency가 추가됩니다. 각 고객의 feature set을 짧은 TTL(시간이 아닌 분 단위)로 cache하고, grant의 state가 변경되면 webhook handler에서 cache를 invalidate하세요. 이렇게 하면 checks는 빠르게 유지되고 revoke는 다음 request부터 적용됩니다.

라이프사이클

Feature flag grants는 표준 grant lifecycle을 따르되 한 가지 단순화된 점이 있습니다. delivery 단계가 없으므로 grants는 Pending에 머무르지 않으며 Failed로도 이동하지 않습니다. Grants는 entitlement 및 customer별로 idempotent합니다. 고객에게 flag에 대한 revoke되지 않은 grant가 있는 동안에는 반복 구매와 renewal이 duplicate를 생성하지 않습니다.

웹훅

polling 대신 flag를 자체 database에 mirror하려면 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
delivery가 전부 Dodo Payments 내부에서 처리되므로 Feature flags에서는 entitlement_grant.failed가 절대 발생하지 않습니다.

예제: Pro Plan으로 Advanced Reports 잠금 해제

  1. flag를 생성합니다. feature_id: advanced_reports를 설정하고 metadata { "tier": "pro", "monthly_report_limit": 100 }를 추가합니다.
  2. 연결합니다. Pro Plan subscription product에 flag를 연결합니다.
  3. 고객이 subscription을 시작합니다. Dodo Payments가 Delivered grant를 생성하고 entitlement_grant.created를 발생시킵니다. webhook handler는 고객에 대해 advanced_reports를 활성화하고 limit를 100으로 설정합니다.
  4. 앱이 feature를 gate합니다. dashboard를 로드할 때 cached feature set을 확인하거나(또는 listEntitlementGrants를 호출하여) advanced_reports가 있을 때만 reports tab을 렌더링합니다.
  5. 고객이 취소합니다. Dodo Payments가 grant를 revoke하고 entitlement_grant.revoked를 발생시키면 handler가 feature를 비활성화합니다. 이후 subscription이 dunning을 통해 복구되면 entitlement_grant.delivered가 code 변경 없이 feature를 복원합니다.

모범 사례

  • snake_case에서 stable feature IDs를 사용하세요. 애플리케이션 code가 이 strings를 확인하므로 하나의 이름을 변경하면 양쪽 모두에서 breaking change가 발생합니다.
  • capability당 하나의 flag를 사용하세요. 단일 pro_bundle보다 advanced_reports와 api_access를 두 개의 entitlements로 사용하는 편이 좋습니다. 그래야 revoke와 plan combinations를 깔끔하게 유지할 수 있습니다.
  • webhooks로 state를 구동하고 API로 확인하세요. Webhooks는 database를 최신 상태로 유지합니다. list endpoint는 reconciliation jobs와 cache misses를 위한 source of truth입니다.
  • Revoked를 즉시 적용되는 것으로 처리하세요. revoked flag는 고객이 더 이상 해당 feature에 대해 payment하지 않음을 의미합니다. 다음 session이 아니라 다음 request에서 gate하세요.
  • limits는 code가 아닌 metadata에 넣으세요. quota를 변경할 때 entitlement만 편집하면 됩니다. 신규 고객은 새 값을 받고 기존 grants는 구매 당시의 snapshot을 유지합니다.
마지막 수정일 2026년 9월 26일