Enforced, not promised.
Plans, seats and credit balances enforced at request time — zero added latency, zero drift between what customers pay for and what they can do. Flip a feature for one cohort from the dashboard.
Updated August 2026Access that matches the invoice, always.
Three steps. No engineering ticket.
Set what each plan, seat count and credit balance unlocks — enforced the same place pricing lives.
One API call, or the edge SDK with local caching, answers 'can this customer do this right now?'.
A wallet emptying or a plan changing updates access in the same second — no separate sync job to break.
Access that reads the same ledger that bills.
An entitlement check answers one question: can this customer do this, right now? It's a single API call that reads plan, seat count and live credit balance — the same data that drives invoicing, not a separate permissions system that has to be kept in sync by hand.
For requests where even a normal API round-trip is too slow, the edge SDK caches checks locally so the hot path adds effectively zero latency. That local cache stays consistent with the source of truth in the ledger — when a wallet empties or a plan changes, the update propagates through rather than leaving a stale cached answer in place.
A blocked check isn't necessarily a dead end for the customer. It can return an upgrade URL that drops them straight into the portal to add a seat, upgrade a plan, or top up a wallet — turning what would otherwise be a hard feature wall into a self-serve expansion moment.
Because entitlements and billing derive from the same ledger, there's no scenario where a customer is charged for access they don't have, or granted access to something they haven't paid for. Feature flags at the cohort level work the same way — flip a feature for a specific plan or segment from the dashboard, and access changes without a deploy.
FAQ
Does an entitlement check slow down my product's requests?
No — the edge SDK caches checks locally, so the hot path sees effectively zero added latency. That cache stays consistent with the ledger, so you get speed without trading away correctness.
What happens the moment a customer's wallet runs out?
Access updates in the same second, because entitlement checks read from the identical ledger that tracks the balance — there's no separate sync job that could lag behind or fail silently.
Can I gate a single feature for just one cohort or plan?
Yes — feature flags can be scoped to a specific plan, seat tier or customer segment and flipped from the dashboard, with the change taking effect immediately rather than requiring a deploy.
What does a blocked entitlement check actually return?
It can return an upgrade URL that routes the customer directly into the portal to upgrade their plan, add seats, or top up their wallet — so a blocked feature becomes a self-serve expansion path instead of a dead end.
How is entitlement data kept in sync with billing?
It isn't "kept in sync" in the traditional sense — there's no separate system or job reconciling the two. Entitlements and billing both derive from the same ledger, so there's nothing to sync and nothing that can drift out of alignment.