Spend & Usage Controls

Usage-based pricing puts two parties at risk. You need protection from a customer whose usage outruns what they are paying for, and the customer needs protection from a bill they did not see coming. The same set of controls solves both, pointed in different directions.

This page is a map of what exists and where to find it. The detailed setup lives on the pages linked from each section.

The controls at a glance

Limits on metered features

Three limit types apply to features metered against usage, and they behave differently at the boundary.

A hard limit is the point at which access is restricted. For usage included with a plan, that is the included amount. For pay as you go and overage pricing, where usage is not otherwise bounded, it is an upper bound you set to prevent abuse or runaway spend. It is normally hidden from the customer.

A soft limit does not restrict anything. Under overage pricing it marks where billed usage begins, and it is shown to the customer in Schematic components so they know when they cross from included usage into paid usage.

A tier limit fires as a company crosses into each successive pricing tier under tiered pricing, which lets you tell them the rate is changing before the invoice does.

Each type has a warning event that fires on approach and a reached event that fires at the boundary, so you can act before rather than after. The warning thresholds are fixed:

Controls on a credit balance

For credit burndown plans, the balance itself is the limit. A company can only spend what it holds, so the controls are about what happens as the balance runs down.

Credit limit events fire as a credit-backed feature draws down what a company holds. credit.limit.warning fires at 80% and credit.limit.reached at 100%.

Auto top-up refills the balance automatically when it drops below a threshold, so a customer is not cut off mid-workload. Whether you or the customer operates it is the Top-up Availability setting on the credit grant. See Who controls auto top-up.

Bundle purchasing lets a customer buy more credits on demand, controlled by the Buyers can purchase credit bundles checkbox on the same grant. It is independent of top-up availability, so you can offer one without the other.

Which credits get spent first, and what happens to an unused balance at the end of a period, are covered in Consumption order and Credit lifecycle.

Exceptions for a single company

Everything above is set on a plan or a credit grant, so every company on that plan inherits it. When one company needs different treatment, an override changes the entitlement for that company alone.

Overrides can be time-limited, which is the right shape for a temporary increase you do not want to become permanent. See Manage exceptions with overrides.

Auto top-up is the exception to the exception: its per-company settings are only reachable through the API, not the dashboard.

Making the controls visible to customers

A limit the customer cannot see is a support ticket waiting to happen. Two surfaces close that gap:

• Components show current usage against entitlements in the customer portal, including credit balances and the soft limit at which billed usage begins. See the Element Library.
• Webhooks let you drive your own in-app banners and emails off the same warning events your internal alerting uses. Subscribe under Settings > Integrations > Webhooks, and see Entitlement & Credit Trigger Webhooks for the payloads.

Wiring the warning events, not just the reached events, is what turns a hard stop into something the customer saw coming.