Admin API Rate Limits

Each Admin API key has a request-rate limit and a monthly request quota. These limits apply to resource requests at https://admin.mimeeqapi.com/v1 where rate limiting is enabled. The Embed API has its own limits.

Rate-Limit Tiers

Each Admin key has an assigned tier:

Tier	Sustained requests per second	Burst capacity	Requests per UTC calendar month
BASIC	5	25	100,000
STANDARD	25	50	2,000,000
PREMIUM	100	200	20,000,000

The request-rate limit uses a token bucket. Each request spends one token, and tokens refill continuously at the tier's sustained rate, up to its burst capacity. For example, a BASIC key with a full bucket can make 25 requests in quick succession; it then replenishes five tokens per second. Burst capacity does not increase the monthly quota.

All endpoints and clients using the same Admin key share its request-rate limit and monthly quota. Coordinate workers that use the same key. Contact Mimeeq support to confirm your key's tier or discuss higher throughput requirements.

How Requests Are Counted

A request admitted by the rate limiter consumes one token and one request from the monthly quota, even if validation or the resource handler later returns an error. Each HTTP request has the same cost: a bulk operation or a page of results counts as one request, regardless of the number of records it contains.

Requests rejected during authentication or scope checks, and requests rejected with rate_limit_exceeded or quota_exceeded, do not consume this allowance.

The monthly quota resets at 00:00 UTC on the first day of each calendar month.

Response Headers

When a request is admitted by the rate limiter, its response includes these headers, including when the resource operation returns an error:

Header	Meaning
RateLimit-Limit	The key's burst capacity: 25, 50, or 200 requests.
RateLimit-Remaining	Whole tokens remaining after this request.
RateLimit-Reset	Seconds until the bucket would be full again if no more requests were made. This is a duration, not a Unix timestamp.

For example, the first request against a full BASIC bucket returns:

RateLimit-Limit: 25
RateLimit-Remaining: 24
RateLimit-Reset: 1

These headers describe the request-rate bucket. They do not report the monthly quota or its remaining allowance. Read the headers when present instead of hard-coding a burst capacity. Headers are optional when rate limiting is disabled or temporarily bypassed; their absence does not establish an unlimited allowance.

Handling HTTP 429

Both limit types return 429 Too Many Requests in the Admin error envelope. Check the error code to choose the next step:

Code	Cause	Retry behavior
rate_limit_exceeded	The request-rate bucket has too few tokens for another request.	Wait at least the number of seconds in Retry-After, then retry at a lower rate.
quota_exceeded	The key's monthly request quota is used up.	Pause requests until the next UTC month, or contact support about your allowance. Retry-After gives the seconds until that reset.

Request-Rate Limit

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 1
RateLimit-Limit: 25
RateLimit-Remaining: 0
RateLimit-Reset: 5

{
  "code": "rate_limit_exceeded",
  "message": "Too many requests for this API key.",
  "requestId": "example-request-id"
}

Use Retry-After for the minimum retry delay. RateLimit-Reset describes the time to a full bucket, which can be longer than the wait for one token. Other workers using the key can consume replenished tokens, so a retry may still receive 429.

Monthly Quota

{
  "code": "quota_exceeded",
  "message": "The monthly request quota for this API key is used up.",
  "requestId": "example-request-id"
}

This response includes Retry-After with the number of seconds until the next UTC month. It omits all three RateLimit-* headers because bucket capacity does not describe an exhausted monthly quota. Repeated immediate retries will not restore the allowance.

Requests rejected with either of these 429 codes are stopped before the resource operation runs.

Temporary Unavailability

If rate-limit enforcement is temporarily unavailable, a request may be allowed through without RateLimit-* headers or receive 503 Service Unavailable with code service_unavailable and Retry-After: 30.

Honor Retry-After on 503 responses as well as 429 responses. The value is a delay in seconds. See Admin API Conventions for handling writes after timeouts or connection failures.

Plan Your Integration

• Bound concurrency and pace requests across all workers sharing a key.
• Use pagination and supported bulk operations to reduce the number of calls. Respect each operation's page-size and payload limits.
• Honor Retry-After, add a small random delay to spread simultaneous retries, and cap retry attempts.
• Pause work on quota_exceeded instead of using a short retry loop.
• Save the error requestId for diagnostics. Recognized-key 429 responses appear in Requests Log, without request or response bodies.