Can I use feature flags for entitlements?

Yes. A targeting rule keyed on the plan attribute you pass at evaluation is a working entitlement gate: it serves the paid variation to customers on your paid tiers and the off variation to everyone else. You can layer a per-customer override on top to grant early access, and you can reference a reusable segment so the same tier definition drives every gated flag. The flag owns the access decision; your billing system stays the source of truth for which plan each customer is on.

What is the difference between feature flags and an entitlements platform?

A feature flag makes the access decision: given the plan you pass, does this customer see this feature. An entitlements platform manages the state behind that decision, syncing plans from billing events, metering usage against quotas, and driving upgrade and checkout flows. The two compose. The flag is the enforcement point in your application, and it reads the plan your billing or entitlements system owns. Many teams need only the gating side, and a flag covers that completely.

How do I gate a feature by plan tier?

Pass the customer's plan in the evaluation context, then add a targeting rule that serves the on variation when plan is in your paid tiers and leaves the fallthrough off. For example, a rule of plan in pro, enterprise turns a premium feature on for those customers and off for free accounts. To reuse the same tier logic across many features, define a segment for your paid plans once and reference it from each gated flag rather than recreating the rule.

Can I set different limits per plan, like seats or projects?

Yes. A multivariate flag serves a different value per tier, so one flag can return a seat or project limit that varies by plan: three for free, twenty-five for pro, unlimited for enterprise. Your application reads the number with a typed evaluation such as intVariation and enforces it. The tier-to-limit mapping lives in the flag's rules, so raising a limit or re-packaging a tier is a dashboard change rather than a deploy.

Does Featureflip handle billing or usage metering?

No, and that is deliberate. Featureflip reads the plan you pass and makes the access decision in sub-millisecond local evaluation. It does not manage subscriptions, count usage, or enforce quotas. Those stay in your billing and usage systems, which remain the source of truth. Pass the current plan on every evaluation and the gate always reflects the live subscription. If you need metering, quotas, or a checkout flow, pair the flag with a billing or entitlements platform that owns that state.

Can I grant one customer early access to a paid feature?

Yes. Add a rule that targets a specific organization or user id above the tier rule, so it matches first and serves the on variation regardless of plan. That gives a single account early access, a trial of a premium feature, or a contractual exception without touching the tier rule everyone else falls through. Removing the override later is a dashboard change, and every SDK picks it up over the stream within a second or two.

Feature flags for entitlements and plan gating

Serve a paid feature to the tiers entitled to it, change who gets it from the dashboard, and keep your billing system as the source of truth for the plan. The flag enforces access; billing owns the plan.

Last updated: June 30, 2026

An entitlement is the rule that decides which customers get access to a feature, usually by plan tier. A feature flag is a clean way to enforce it. You pass the customer's plan as an attribute at evaluation, and a targeting rule serves the paid variation to the tiers entitled to it while everyone else falls through to off. Because the rule lives in configuration, moving a feature between tiers is a dashboard change rather than a deploy, and you can override a single customer to grant early access. What a flag does not do is manage the subscription itself: which plan a customer is on, whether it is current, and how much of a quota they have used all stay in your billing system. The flag owns the access decision; billing owns the plan. For the mechanics, see how targeting rules and segments work.

Get started free Read the targeting docs

Why gate entitlements behind a flag?

Four reasons teams reach for a flag when they want features to switch on by plan.

1
Change access without a deploy
Packaging changes as the product grows: a feature moves from enterprise-only into pro, or a new tier appears. When the entitlement lives in a targeting rule, that is a dashboard edit. The application code that asks whether the feature is on never changes, so re-packaging does not wait on a release.
2
Gate on context you already pass
Plan tier is just an attribute in the evaluation context, next to the user and organization id you already send. A rule matches on it directly, and a segment groups your paid tiers once so every gated feature can reference the same definition instead of repeating it.
3
Grant early, or roll out gradually
Override a single account to give a customer early access ahead of their tier, or stack a percentage rollout under the tier rule to release a new premium feature to a slice of paid users first. The same flag handles the entitlement and the gradual release together.
4
Fast enough for the hot path
An entitlement check runs on nearly every request that touches a gated feature. The SDK evaluates from an in-memory copy of the config, so the check adds no network hop and no measurable latency. Gating premium features does not slow the requests that use them.

What entitlements need, and which half a flag covers

Entitlements have an enforcement side and a management side. Feature flags own the enforcement side completely. The management side stays with the billing system you already run.

Part	Where it comes from	What it covers
The access rule per tier	The feature flag	A targeting rule keyed on the plan attribute serves the paid variation to the tiers entitled to it and the off variation to everyone else. Reorder the tiers or add one from the dashboard.
Per-customer overrides	The feature flag	Target a single organization or user above the tier rule to grant a feature ahead of its plan, honour a contract, or hold one account back, without a code change.
The plan each customer is on	Your billing system	The flag reads the plan you pass at evaluation. Which plan a customer is on, and whether their subscription is current, stays authoritative in the billing system you already run.
Usage metering and quotas	Your billing or usage system	Counting API calls, seats, or events against a plan limit is a job for a metering system. A flag makes a yes-or-no decision; it does not tally usage or enforce a running total.
The upgrade flow	Your billing or paywall	A flag gates the locked feature and you can show an upsell in its place, but taking payment and moving the customer to a higher plan is the billing product's job, not the flag's.

That division is the whole mental model. The flag guarantees a fast, consistent access decision from the plan you pass. Whether a subscription is current, how much of a quota is left, and how a customer upgrades are questions your billing system answers. Enforcing access by segment targeting on plan is the same rule machinery a targeted rollout uses, pointed at tiers instead of a cohort.

How to gate a feature by plan tier

Six steps. The first is code; the rest are configuration you change without shipping.

Step	What you do	Detail
1	Create the gate	Add a boolean flag for the premium feature with its off variation as the fallthrough, so a customer sees the feature only when a rule grants it.
2	Pass the plan in context	Include the customer's plan alongside their user and organization id on every evaluation. The flag can only gate on an attribute your app actually sends.
3	Add a tier rule	Configure a rule that serves the on variation when plan is in your paid tiers, for example pro or enterprise, and leave the fallthrough off for free accounts.
4	Reuse a segment	Define a "Paid plans" segment once and reference it from every gated flag. Change the definition in one place and it updates across all of them.
5	Override per customer	Target a specific organization id above the tier rule to grant early access, run a trial of a premium feature, or honour a bespoke contract.
6	Change access live	Move a feature between tiers in the dashboard when packaging changes. Every connected SDK picks up the new rule over the stream within a second or two, with no redeploy.

Steps three and four are ordinary targeting rules and segments, the same building blocks a beta program or a regional launch uses. Point them at plan and they become entitlement gates. Reorder the rules so a per-customer override sits above the tier rule, since the first match wins.

How Featureflip handles the gating side

The rule and evaluation mechanics that turn a plan attribute into a fast, consistent access decision, so the only thing your billing system owns is the plan itself.

Attribute targeting on plan. A rule serves the on variation when plan is in your paid tiers. Rules run top to bottom and the first match wins, so a specific customer override can sit above the broad tier rule. See the targeting docs for operators and ordering.
Reusable segments. Define a "Paid plans" or "Enterprise" segment once and reference it from every gated flag. Update the definition in one place and it propagates to all of them, so renaming or adding a tier is a single edit. See the segments guide.
Different limits per tier. A multivariate flag serves a different value per plan, so one flag can return a seat or project limit that varies by tier. Your app reads it with a typed evaluation and enforces the number, with the mapping held in the flag rather than in code.
Per-customer overrides. Target a single organization or user id to grant a feature ahead of its tier, run a trial, or honour a contract, independent of the plan rule everyone else falls through.
Sub-millisecond local evaluation. The gate runs against an in-memory copy of the config, so an entitlement check on the hot path adds no network hop. The config stays local even if the control plane has a blip.
Real-time changes. Move a feature between tiers in the dashboard and every connected SDK picks up the new rule over a Server-Sent Events stream within a second or two, fleet-wide, with no redeploy.

What it looks like in your app

The application passes the plan in the evaluation context and asks the flag whether the feature is available. The last argument is the fallback, returned if the SDK cannot reach Featureflip, so the locked state doubles as the safe default:

const context = {
  user_id: 'user-456',
  org_id: 'org-123',
  plan: 'pro', // from your billing system
};

// 'false' is the safe fallback: served when the plan is not
// entitled, or when the SDK can't reach Featureflip.
if (client.boolVariation('advanced-analytics', context, false)) {
  return renderAdvancedAnalytics(context);
}
return renderUpgradePrompt(context);

A tiered limit works the same way. A multivariate flag returns a different value per plan, so one call gives you the seat or project cap for this customer's tier:

// A different limit per tier: 3 on free, 25 on pro,
// unlimited on enterprise. '3' is the offline fallback.
const seatLimit = client.intVariation('seat-limit', context, 3);

The tier rules live entirely in the dashboard. Move advanced-analytics from enterprise into pro, or raise the seat-limit for a tier, and every SDK reflects it on its next evaluation without a rebuild. Because the fallback is the locked value, an outage fails safe to the free experience rather than handing out a paid feature. The same surface works in every language the platform supports, from Python and Go to C#, Java, and Node. Pick a quickstart from the SDK overview.

Entitlement gating vs entitlement management

A flag covers the gating side. A billing or entitlements platform covers the management side. Knowing which one you need keeps you from asking a flag to do a billing system's job.

Dimension	Entitlement gating (a flag)	Entitlement management (billing)
Question it answers	Can this customer use this feature?	What is this customer entitled to, and have they hit their limit?
What it owns	The access decision, per tier and per customer	Plan state, usage metering, quotas, billing sync
Source of truth	Reads the plan you pass in	Owns the subscription and usage record
How access changes	Flip a rule in the dashboard, no deploy	Plan changes flow from billing events
Right tool	A feature flag	A billing or entitlements platform

They compose. The flag is the enforcement point inside your application, and it reads the plan your billing system owns. If all you need is to switch features on by tier, a flag is the whole answer. If you also need metering, quotas, and a checkout flow, pair the flag with a platform that owns that state and let the flag do the gating in front of it.

Common mistakes to avoid

The patterns that turn a clean entitlement gate into a support ticket. Most of them come from asking the flag to own something billing should.

Treating the flag as the billing source of truth

A flag enforces access; it does not know that a card was declined or a subscription lapsed. If the flag holds a stale copy of the plan, a downgraded customer keeps a paid feature. Keep billing authoritative and pass the current plan on every evaluation, so the gate always reflects the live subscription rather than a snapshot.

Hard-coding the tier list in application code

Writing if plan === 'pro' checks scattered through the codebase pulls the packaging decision back into the deploy pipeline. Every time a feature moves tiers, someone edits and ships code. Put the tier-to-feature mapping in targeting rules or a segment instead, so re-packaging is a dashboard change and the application code just asks whether the feature is on.

Forgetting the safe default

The fallback passed to the evaluation is what the SDK returns if it cannot reach Featureflip. For an entitlement that value should be the locked state, so an outage never hands a paid feature to a free account. Default to off and let a matched rule turn the feature on, never the other way around.

Trying to meter usage with a flag

A flag returns a value; it does not keep a running count. Enforcing 'up to 100 API calls a month' by toggling a flag when the limit is hit means something else is doing the counting anyway. Leave quotas and metering to your usage system and let the flag gate the on-or-off availability of the feature.

Duplicating the same tier rule across flags

Copying plan in [pro, enterprise] onto forty flags means forty edits the day you rename a tier or add one. Define the tier once as a segment and reference it everywhere. One update to the segment definition propagates to every flag that uses it, which is the whole reason segments exist.

When a flag-driven entitlement is the wrong tool

A flag makes gating easy, but it is not a billing system. A few cases call for something more:

You need usage metering and hard quotas. Counting API calls or events and enforcing a monthly limit is a metering job. A flag gates the on-or-off availability of a feature; it does not keep a running total. Meter in your usage system and let the flag gate the feature around it.
Entitlements must sync from the billing lifecycle. Trials expiring, dunning, proration, and mid-cycle upgrades are subscription events. A dedicated billing or entitlements platform models them; the flag only reads the plan those systems produce. Keep that state authoritative and pass the result in.
You are building a self-serve paywall with checkout. A flag can gate the locked feature and you can render an upsell in its place, but taking payment and moving the customer to a new plan belongs to a billing or paywall product.
Entitlements are contractual and per-customer at scale. Hundreds of bespoke, negotiated entitlements with complex rules are better modelled in an entitlements service. A flag still enforces the final gate in your app, reading the entitlement that service resolves.

Frequently asked questions

Can I use feature flags for entitlements?: Yes. A targeting rule keyed on the plan attribute you pass at evaluation is a working entitlement gate: it serves the paid variation to customers on your paid tiers and the off variation to everyone else. You can layer a per-customer override on top to grant early access, and you can reference a reusable segment so the same tier definition drives every gated flag. The flag owns the access decision; your billing system stays the source of truth for which plan each customer is on.
What is the difference between feature flags and an entitlements platform?: A feature flag makes the access decision: given the plan you pass, does this customer see this feature. An entitlements platform manages the state behind that decision, syncing plans from billing events, metering usage against quotas, and driving upgrade and checkout flows. The two compose. The flag is the enforcement point in your application, and it reads the plan your billing or entitlements system owns. Many teams need only the gating side, and a flag covers that completely.
How do I gate a feature by plan tier?: Pass the customer's plan in the evaluation context, then add a targeting rule that serves the on variation when plan is in your paid tiers and leaves the fallthrough off. For example, a rule of plan in pro, enterprise turns a premium feature on for those customers and off for free accounts. To reuse the same tier logic across many features, define a segment for your paid plans once and reference it from each gated flag rather than recreating the rule.
Can I set different limits per plan, like seats or projects?: Yes. A multivariate flag serves a different value per tier, so one flag can return a seat or project limit that varies by plan: three for free, twenty-five for pro, unlimited for enterprise. Your application reads the number with a typed evaluation such as intVariation and enforces it. The tier-to-limit mapping lives in the flag's rules, so raising a limit or re-packaging a tier is a dashboard change rather than a deploy.
Does Featureflip handle billing or usage metering?: No, and that is deliberate. Featureflip reads the plan you pass and makes the access decision in sub-millisecond local evaluation. It does not manage subscriptions, count usage, or enforce quotas. Those stay in your billing and usage systems, which remain the source of truth. Pass the current plan on every evaluation and the gate always reflects the live subscription. If you need metering, quotas, or a checkout flow, pair the flag with a billing or entitlements platform that owns that state.
Can I grant one customer early access to a paid feature?: Yes. Add a rule that targets a specific organization or user id above the tier rule, so it matches first and serves the on variation regardless of plan. That gives a single account early access, a trial of a premium feature, or a contractual exception without touching the tier rule everyone else falls through. Removing the override later is a dashboard change, and every SDK picks it up over the stream within a second or two.

Gate your next paid feature behind a flag

Free Solo plan covers 10 flags and 2 environments. No credit card, no demo call: create a flag and add a tier rule.

Get started free See pricing

Feature flags for entitlements and plan gating

Why gate entitlements behind a flag?

Change access without a deploy

Gate on context you already pass

Grant early, or roll out gradually

Fast enough for the hot path