Skip to content
P

Plans, entitlements & billing

How plan tiers map to entitlements, how usage is metered, and where limits are enforced.

Every organisation is on a plan tier, and the tier is what governs how much of the platform the organisation can use. This page explains the model; the generated Plans & limits reference lists the current tiers and their entitlements.

Tiers and entitlements

There are several tiers, from a free tier up to enterprise. A tier resolves to a set of entitlements — named limits and feature flags such as the API rate limit, usage caps, and access to particular capabilities. Most entitlements come from a shared set of defaults; a tier overrides the ones that differ (for example, the per-minute API rate limit is pinned per tier). This keeps the model consistent: adding a new limit means adding it to the defaults, and only the tiers that deviate carry an override.

Metering

Usage-based entitlements are metered. As requests flow through the API, a metering step records usage against per-organisation counters; a rollup worker aggregates them. Metering is best-effort and fully guarded — a metering failure never fails the underlying request. This gives billing an accurate, auditable view of usage without putting the billing path in the critical path of every API call.

Where limits are enforced

  • Rate limits are enforced by a Redis sliding-window limiter, per plan, on the API. Exceeding a limit returns a rate-limit error with the standard headers — see the Rate limits guide.
  • Feature entitlements are checked where the feature is used.
  • Usage caps are enforced against the metered counters.

Who manages billing

A platform admin manages tiers and per-tenant subscriptions across organisations; an organisation admin can see their own plan and usage. See the Org admin guide and the Platform admin quickstart.

Related