Docs/Guides/

Entitlements

Manage paid features and plan limits centrally while keeping billing and authorization on the server.

Simplify your product packaging

  1. 1.Define capabilities
  2. 2.Target by plan
  3. 3.Enforce on the server

Your pricing should not be buried in dozens of scattered plan checks. Use flags to define product capabilities, target them by subscription plan, and show the right experience to each customer. Keep billing as the source of truth and permissions enforced on the server.

Turn packaging changes into configuration

Business needFlag-based approach
Offer analytics on Pro and EnterpriseOne capability flag with plan targeting
Test a new package before a broad launchExplicit rules for a controlled audience
Change upload limits by planA number flag with plan-specific values
Offer trial accessA trusted trial attribute with a higher-priority rule

Once the application is wired to those capabilities, supported configuration changes do not require rewriting each plan check. New features, billing behavior, and authorization policies can still require code changes.

Flags are not a security boundary. A browser can modify client-supplied context. Verify subscriptions and enforce protected actions, data access, and usage limits on the server. Do not treat a visible button as proof of permission.

Set up a paid capability

1. Pass trusted subscription context

Integrate the SDK for your runtime. Obtain the customer's current plan from your authenticated billing or account data, then pass it in context:

client.updateContext({
  userId: user.id,
  plan: account.subscription.plan, // 'free', 'pro', or 'enterprise'
})

This example assumes an initialized client and account data supplied by your application. For team subscriptions, use the active account's plan, not an unrelated personal subscription.

2. Define a capability rather than a plan check

Create a boolean flag called advanced-analytics:

SettingValue
Variation 0true — show advanced analytics
Variation 1false — show the standard experience
Default variation1 — disabled for unmatched users
Rollout percentage100% — plan rules control access

Add the plan rules:

PriorityAttributeOperatorValueReturn
0planeq"enterprise"Variation 0
1planeq"pro"Variation 0

The first matching rule wins. Free, missing, or unrecognized plans receive the disabled default. This keeps the app asking “is advanced analytics available?” rather than encoding your pricing table in every component.

3. Show the appropriate experience

if (client.isEnabled('advanced-analytics', false)) {
  showAnalyticsDashboard()
} else {
  showUpgradePrompt('Advanced analytics is available on Pro')
}
import { useFlag } from '@flagpool/react'

function AnalyticsPage() {
  const hasAnalytics = useFlag('advanced-analytics', false)

  return hasAnalytics ? (
    <AnalyticsDashboard />
  ) : (
    <UpgradePrompt feature="Advanced analytics" plan="Pro" />
  )
}

Keep the API's authorization check independent of this UI decision. Validate both the flag configuration and the server's permission checks before exposing paid functionality.

Configure limits without scattering constants

For max-upload-size-mb, use a number flag:

VariationValueTargeting
0 — Free10Default for unmatched users
1 — Pro100plan eq "pro" → variation 1
2 — Enterprise1000plan eq "enterprise" → variation 2

Set the default to variation 0 and the rollout to 100%. A lower rollout can give unmatched users the off variation (typically index 1), which in this example is the larger Pro limit.

Use the value to display the correct limit in the UI, and enforce the permitted upload size on the server. Decide explicitly what the server should do if configuration is unavailable; never turn an unknown limit into unlimited access.

Handle upgrades, downgrades, and trials

After your server confirms a subscription change, refresh the trusted account data and update SDK context. In React, call setContext from useFlagpool(); in JavaScript, use client.updateContext(). Also refresh server-side access decisions.

For a trial, supply a server-derived isTrial attribute and add a higher-priority isTrial eq true rule returning the enabled variation. Your application owns trial expiry: update context when the trial ends so the actual plan's rules apply again.

On account switching or sign-out, replace old plan and trial attributes with the current account's values. Verify downgrade behavior as carefully as upgrades, and explain any changed access to the customer.

Configuration is not billing synchronization. Flags do not process payments or confirm a subscription. Dashboard changes reach applications after publication and SDK refresh; billing events, cached configurations, and connectivity can affect when an experience changes.

Ready to gate a paid feature?

  • Subscription and trial attributes come from trusted account data.
  • Free, paid, unknown, and missing plans receive the intended values.
  • Unmatched users cannot get a paid limit through the off variation.
  • Protected actions and limits are enforced on the server.
  • Upgrade, downgrade, trial expiry, account switching, and sign-out are covered.
  • Loading and unavailable-configuration behavior is explicitly defined.

Extend your packaging

  • Targeting — configure rule priority and plan matching.
  • Flag types — use number and JSON values for product configuration.
  • Contexts — keep user and account attributes current.

Start Managing Feature Flags Today

Join teams who trust Flagpool to deliver features safely and efficiently.

No credit card required • Cancel anytime