Rate-limit policy belongs in your spec.
Define rate limits as x-apistaq-policy annotations directly in your OpenAPI file — next to the endpoints they govern. Choose token bucket, sliding window, or fixed window per endpoint. No separate gateway DSL, no secondary config file, no drift between what the spec says and what the gateway enforces.
Policy-as-code: from spec annotation to enforced limit.
Spec-native policy — no secondary config
Write x-apistaq-policy annotations in the same YAML file as your endpoint definitions. The policy lives with the contract it describes. No separate gateway configuration file, no policy-language DSL to learn, no manual reconciliation when the spec changes.
Three-level policy inheritance
Set a global default at the spec root, override by OpenAPI tag (e.g., premium consumers vs. free tier), and override again per-endpoint. Apistaq resolves the most specific applicable policy at request evaluation time. No code required — inheritance is declarative in the spec.
Token bucket, sliding window, fixed window
Configure the algorithm via the algorithm key in your policy annotation. Token bucket suits bursty workloads. Sliding window is accurate for strict per-minute enforcement. Fixed window is lowest overhead for internal APIs with predictable traffic. Sliding window is the default.
RFC-compliant 429 + Retry-After
Apistaq enforces standard 429 Too Many Requests with Retry-After headers, following RFC 6585. Your SDK codegen picks up the 429 response schema automatically — typed error classes, retry logic, and backoff are generated from the same spec that defines the limit.
One place to define rate-limit policy. Everywhere it enforces.
Global policies on Free. Per-endpoint policies and burst-key configuration on Builder and Platform. No more drift between what the spec says and what the gateway does.
Start free