Quotas and Limits
Numeric entitlements, or quotas, are plan limits managed by Billing (PBM). They limit how many of a particular resource a tenant or customer can create. The platform counts existing active resources and compares the count to the resolved limit before allowing a new resource to be created.
How quota counting works
Each quota feature defines which type of resource is counted and what counts toward the limit (for example, only active resources rather than all resources).
When a user attempts to create a new resource that is governed by a quota, the system:
- Counts the current active resources for the relevant scope (tenant or customer).
- Compares the count against the resolved entitlement limit.
- Allows the operation if the count is below the limit, or denies it with a 429 Too Many Requests error if the limit would be exceeded.
Counting at each layer
Quotas are counted independently at each enforcement layer. For a feature with enforcement scope BOTH, both checks must pass:
Tenant-level counting
The tenant-level count includes all active resources across the entire tenant, regardless of which customer they belong to. The resolved limit takes the platform ceiling into account — the effective limit is the lower of the platform limit and the tenant limit.
If the tenant has 45 active application instances and the effective tenant limit is 50, a new instance is allowed. If the tenant limit is 50 but the platform ceiling is 40, the effective limit is 40 and the request is denied.
Customer-level counting
The customer-level count includes only the active resources that belong to the current customer.
For example, if Customer A has 8 active application instances and their customer entitlement limit is 10, a new instance for Customer A is allowed — even if the tenant as a whole is near its tenant-level limit.
Both checks must pass
For features scoped as both, the system enforces the tenant-level and customer-level quotas independently. A request can be denied at either layer:
| Tenant count | Tenant limit | Customer count | Customer limit | Result |
|---|---|---|---|---|
| 45 | 50 | 8 | 10 | Allowed |
| 50 | 50 | 8 | 10 | Denied (tenant limit reached) |
| 45 | 50 | 10 | 10 | Denied (customer limit reached) |
| 50 | 50 | 10 | 10 | Denied (both limits reached) |
When a limit is reached
When a quota check fails, the API returns a 429 Too Many Requests error. The error includes a message indicating which quota was exceeded and the current usage. This error can come from either the tenant-level or customer-level check.
Common causes:
- The tenant has reached its limit for a resource. This could be because the tenant's own limit is reached, or because the platform ceiling (set by Raytio) is lower than the tenant's configured limit.
- The customer has reached its limit for a resource within the tenant.
- The platform ceiling is lower than expected because the tenant's Raytio subscription has been downgraded or has not been upgraded to include a higher limit.
If you receive a 429 error when creating a resource, check your organisation's current usage against your plan limits. You may need to remove unused resources or upgrade your subscription.
Nested resources
Some resources belong to a customer indirectly through a parent record. For example, an access application instance belongs to an access application, which in turn belongs to a customer.
Limits apply per customer even for nested resources — if a customer has a limit of 5 application instances, that limit is enforced regardless of how many parent applications those instances are spread across.
Features with no quota
Not all plan capabilities are quotas. Boolean features are either enabled or disabled and do not involve counting. A boolean feature must be enabled at every applicable layer (platform, tenant, and/or customer) for it to be available. See Plan Capabilities and Entitlements for how boolean features and quotas fit into the broader billing model.