Entitlements are the rules that define what a customer is allowed to access and how much they can use, based on the plan they bought. They turn a purchased plan into enforceable limits and feature access.
Entitlements are the bridge between billing and the product. When a customer buys a plan, entitlements translate that purchase into concrete permissions: which features unlock, how many seats are allowed, and how much usage is included before overage or blocking kicks in.
How Entitlements works
An entitlement maps a purchased plan to a set of access rules the product checks at runtime. There are three common shapes: boolean (a feature is on or off), numeric (a cap such as seats or projects), and metered (an included quantity of usage, like API calls or tokens, that draws down as it is consumed).
When a user acts, the product asks the entitlement layer whether the action is permitted: is this feature in their plan, are they under their seat limit, do they have usage remaining. The answer enforces the commercial terms of the plan without hard-coding pricing logic into the product.
Entitlements examples
A “Pro” plan entitles the customer to advanced analytics (boolean), up to 10 seats (numeric), and 100,000 API calls per month (metered). The product checks each rule as the customer uses it.
For an AI product, a plan might entitle a customer to 1,000,000 tokens per month with AI token pricing for anything beyond. The entitlement holds the included balance; once it is exhausted, the product either charges overage or blocks, depending on configuration.
Entitlements vs Feature flags
| Entitlements | Feature flags | |
|---|---|---|
| Purpose | Enforce what a plan grants | Toggle code paths on or off |
| Driven by | Billing and plan purchase | Engineering and rollout |
| Examples | Seats, usage caps, plan features | Gradual rollout, A/B test, kill switch |
| Owner | Commercial / billing | Product / engineering |
Benefits & when to use it
Entitlements keep pricing and packaging out of application code. When plans change, you update entitlement rules instead of redeploying the product, which makes packaging experiments cheap and keeps billing and access in sync.
They are essential for any product with more than one plan tier, usage limits, or add-ons. The more a product mixes features, seats, and metered usage, the more an explicit entitlement layer pays off.
FAQ
What is the difference between entitlements and feature flags?
Entitlements enforce what a customer's plan grants (seats, usage caps, included features); feature flags toggle code on or off for rollout or testing. Entitlements are billing-driven; feature flags are engineering-driven. They are often used together.
What are the types of entitlements?
Three common types: boolean (a feature is included or not), numeric (a limit such as seats or projects), and metered (an included quantity of usage that draws down as it is consumed).
How do entitlements relate to billing?
Entitlements are the runtime expression of a billing plan. The plan a customer buys sets the entitlement rules; the product checks those rules to allow or block actions, keeping access aligned with what was sold.
How Credyt handles Entitlements
Credyt enforces metered entitlements in real time against the customer's wallet. Included usage is held as a grant, and each usage event is authorized against the remaining balance before it runs, then debited the moment it is recorded. Stacked grants (bundled, promotional, paid top-up) draw down by priority, so a plan's included quantity and its overage behavior are enforced live rather than reconciled at month end. Explore Credyt →