Skip to main content
A customer negotiates a limit nobody else gets. Another needs a temporary bump while you fix something. A third deserves a credit after an outage. None of these should become a plan. Use an override and your existing checks start answering correctly for that one customer.

​
A negotiated limit

The common case: an annual contract with terms your public pricing doesn’t offer.
This replaces their limit and renews every period like the plan’s own would. Set expiresAt to the contract end date and it stops applying on its own — worth doing, so an expired deal doesn’t quietly outlive the contract.

​
A temporary bump on one counter

On a feature counted per machine, per project or per seat, you can move a single counter and leave the rest on the plan’s limit:
Overrides stack most-specific-first, so “every machine to 3h, except this one at 5h” is two grants rather than one per machine.

​
A one-time credit

This is the one people get wrong. A refund is not a limit change — raising their limit would hand them the same gift every period, forever.
That moves the counter once. Pass an idempotencyKey if the call might be retried.

​
Cleaning up

Expired overrides stay in the list rather than vanishing, so you keep a record of what was promised to whom.
Everything under kerne.admin requires your secret key. Never call these from a request an end user initiated — see Admin access.

​
What an override won’t do

It moves the limit, not the behavior. Whether passing that limit blocks, is tolerated, or gets charged is always read from the plan. If you need a different behavior for one customer, that’s a plan difference, not an override.

​
Next

Overrides

The concept, and how overrides resolve.

Overrides reference

Every option on grant / listGrants / revokeGrant.