Topaz · Rate Limits

Topaz Rate Limits

Topaz does not publish fixed numeric rate limits. Because Topaz is self-hosted (you run the authorizer yourself, typically as a local sidecar or nearby service), authorization throughput is bounded by your own hardware and configuration rather than by a vendor quota. The authorizer is designed for low-latency, high-volume in-process/near-process decisions; the embedded directory and OPA engine evaluate against local data. Any per-tenant quotas or request caps would come from the Aserto hosted control plane, not from the open-source Topaz authorizer.

Topaz Rate Limits is the machine-readable rate-limit profile for Topaz on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 3 rate-limit definitions, measuring decisions and requests.

The profile also includes 2 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Access Control, Authorization, Fine-Grained Authorization, Rate Limiting, and Quotas.

3 Limits Throttle: 429
Access ControlAuthorizationFine-Grained AuthorizationRate LimitingQuotas

Limits

Authorizer Decisions deployment
decisions
hardware-bound
Bounded by your own CPU/memory and replica count; no vendor-imposed cap on self-hosted Topaz.
Directory Reads/Writes deployment
requests
hardware-bound
Directory object/relation/check throughput is a function of the embedded store and your infrastructure.
Aserto Control Plane tenant
requests
per plan
Any request or seat quotas apply to the Aserto hosted control plane, not to the open-source authorizer.

Policies

Sidecar/Local Deployment
Topaz is typically deployed as a sidecar or nearby service so decisions are made with minimal network latency and no external rate limit.
Backoff Strategy
Clients calling a shared Topaz instance should implement exponential backoff with jitter and honor Retry-After on any 429 responses returned by an upstream proxy or the Aserto control plane.

Sources