Overrides

Sooner or later someone negotiates something your catalog doesn’t sell. A yearly contract with a limit nobody else gets. A loaner machine while theirs is repaired. A month of goodwill after an outage you caused. The tempting move is to create a plan for them. Don’t — you’d be adding a product line to solve a conversation, and you’d carry it forever. An override is that deal, attached to one customer, outside your catalog. Every check that already exists in your code starts returning the right answer for them, and nothing changes for anyone else.

Two different things, easy to confuse

Ask which one you mean before reaching for either:

	What it changes	How long
Override	The limit — “this customer has a 1,000/mo deal”	Renews every period like the plan’s own limit, until it expires
Usage adjustment	The counter — “credit them 500 units back”	Once

An override is a standing arrangement. An adjustment is a correction. Giving someone a one-time refund by raising their limit means quietly raising it every month forever.

// A standing deal
await kerne.admin.grant('api_calls', {
  customer: userId,
  value: '50000',
  reason: 'Annual contract - negotiated limit',
  expiresAt: '2027-01-01T00:00:00.000Z', // omit for permanent
});

// A one-time credit
await kerne.admin.adjustUsage('api_calls', { customer: userId, delta: -5000 });

Whole customer, or one counter

Without a dimension, an override covers the customer: on a feature counted per machine or per project, every counter gets that limit of its own. With one, only that counter moves. The two stack, most specific first — a counter uses its own override if it has one, the customer’s otherwise, the plan’s if neither exists. So “every machine to 3h, except this one at 5h” is two overrides, not a list of every machine.

Naming a dimension only does something when the plan limits that feature per dimension. Under a shared pool the override still saves but never resolves — you can’t carve a private allowance out of a pool by naming one machine.

What an override does not touch

What happens past the limit. Block, tolerate, or charge for the excess is always read from the plan’s own entitlement. An override moves the number, not the behavior.
Periods, resets and rollover. Only the limit itself.

Expired overrides stay in the list rather than disappearing, so you keep the audit trail of what was promised to whom. A check result carries has_override when one applied.

Handle customer exceptions

The practical walkthrough, with the common cases.

Overrides reference

grant / listGrants / revokeGrant, every option.

Get started

Core concepts

Users & sign-in

Reference

Two different things, easy to confuse

Whole customer, or one counter

What an override does not touch

Next

Handle customer exceptions

Overrides reference

​Two different things, easy to confuse

​Whole customer, or one counter

​What an override does not touch

​Next

Handle customer exceptions

Overrides reference

Two different things, easy to confuse

Whole customer, or one counter

What an override does not touch

Next