Skip to main content
An entitlement override replaces a customer’s limit for a feature - “this customer has a 1,000/mo deal” - and renews every period exactly like the plan’s own limit would, until it expires (or forever, if you don’t set an expiry). It has no effect on period boundaries, resets, or rollover - only the limit itself.

Customer, or one counter

Without dimension, the grant covers the customer: on a feature limited per dimension, every counter gets that limit of its own. With dimension, only that counter moves. The two stack, most specific first - a counter uses its own grant if it has one, the customer’s otherwise, and the plan’s if neither exists. So “every machine to 3h, except this one at 5h” is two grants, not a list of every machine. A dimension is only read when the plan limits that feature per dimension. Under a shared limit the grant still saves, but never resolves - naming one machine cannot carve a private allowance out of a pool. Passing one on a feature with no dimension key is rejected. Each entry includes is_expired - an expired override still shows up in the list (for audit history), it’s just no longer applied. overage are never overridden this way - they’re always read from the plan’s own entitlement definition. For a one-off credit instead of a standing deal, use adjustUsage() - it touches the counter, not the limit.