Skip to main content
Your plans promise things. “Pro includes SSO.” “Starter gets 10,000 API calls a month.” “Enterprise customers get gold support.” An entitlement is one of those promises, made concrete: a named capability with a value, for one specific customer. It’s what your application asks about, and it’s the reason allows('sso_enabled') can keep working after SSO moves from Pro to Enterprise. Where the value comes from is resolved for you — the plan they’re on, the version of that plan they bought, an override negotiated with them specifically. What you configure is the promise; what your code sees is the answer. Every capability is one of three kinds.

​
The three kinds

An on/off switch. kerne.check() returns { allowed, enabled }.

​
Two ways to deviate from the plan for one customer

These solve different problems - don’t reach for one when you mean the other:
  • kerne.admin.grant() creates an override: a replacement limit that renews every period just like the plan’s own limit, until it expires (or forever). This is “this customer has a 1,000/mo deal,” not a one-time gift. It covers the whole customer, or one counter of a feature limited per dimension.
  • kerne.admin.adjustUsage() offsets the usage counter by a signed delta, once. This is “credit this customer 500 units back,” and has no effect on their limit going forward.

​
Next

Offers and versions

Why changing a plan doesn’t change existing customers.

Checking an entitlement

allows() / check() / enforce(), and every field a check returns.