Skip to main content
The MKA1 API enforces rate limits on a per-key basis. Each API key has its own quota configured independently — requests per minute, hour, or day. When a key exceeds its limit, the gateway returns 429 Too Many Requests before the request reaches the model. No tokens are consumed and no usage is billed.

Rate limit configuration

Rate limits are set per API key at provisioning time. The available granularities are: Each rate-limit configuration holds a single window and maximum — one key cannot combine multiple windows (for example, a per-minute and a per-hour cap on the same key is not supported). Limits stack only across levels: an org-level rate limit (set via PATCH /api/v1/authentication/orgs/{orgId}/rate-limit) and a key-level limit can both apply to the same request.

Demonstration: rate limiting in action

The following example uses a real API key configured with a rate limit of 1 request per minute. The first request succeeds, and the second request — sent immediately after — is rejected with HTTP 429.

Request 1 — succeeds

Response: HTTP 200

Request 2 — rate limited (sent immediately after)

Response: HTTP 429
The gateway rejects the request before it reaches the model — no tokens are consumed and no usage is billed.

Programmatic example

The 429 response

When a request is rate limited, the gateway returns: The OpenAI SDK surfaces this as an OpenAI.RateLimitError with err.status === 429. The MKA1 SDK throws an APIError with err.statusCode === 429.

Handling rate limits in your application

When your application receives a 429 response, retry with exponential backoff:

See also