Rate Limits and Quotas

The API has several different limits, each protecting a different thing. Most requests will only ever bump into the per-minute rate limit. The other caps mainly matter when you submit a lot of jobs at once.

API submissions are always paid with credits, so they run with Premium limits whatever plan you are on, the same as a website run you choose to pay with credits. If you subscribe to a plan with bigger limits, your plan's limits apply instead. The tier numbers below are the Premium ones for that reason.

Per-Minute Rate Limit¶

How many requests you can make in any rolling 60-second window.

• Default: 60 requests per minute, per API key. Platform-wide; not tied to your subscription tier.
• A second cap of 2× the per-key limit applies per user, so creating extra keys does not multiply your quota.
• Unauthenticated requests are limited per IP using the same default.
• Per-key overrides can be raised on request. Email support with the key prefix and the workload.

Concurrent Submissions Cap¶

How many of your submissions can be queued or running at the same time.

• 5 in-flight submissions per user for API runs. The count is shared across web and API, so web runs you already have going take slots too. Per-user overrides may apply.
• An accepted submission occupies a slot immediately, including while it waits in the queue. Completion, failure or cancellation releases the slot.
• Server restarts preserve occupied slots. Rejected requests do not create a submission or consume a slot.
• This cap and the API-specific cap both apply to API submissions. The lower remaining allowance determines whether another API submission can be accepted.

In-Flight API Requests Cap¶

A separate gate on how many runs paid with credits can be queued or running at once for a single user.

• Default: 5 in-flight runs paid with credits per user (per-tier override possible).
• Counts API submissions and website runs paid with credits. Website runs on your plan do not count.
• Mainly a safety valve so a runaway script cannot fill the queue.

Daily Submissions Quota¶

How many new submissions you can create in a rolling 24-hour window.

• 200 submissions per day, sometimes higher per user. Every submission you made in the window counts, web or API.

The window is rolling, not calendar-based: if you submit one job at 9:00 today, that one frees up at 9:00 tomorrow. Moving a submission to Trash or permanently deleting it does not refund this quota.

Per-Tier Parameter Caps¶

Some submission parameters have ceilings checked at submission time. API runs use the Premium column of Plans and tiers, for example:

• num_generations up to 10000.
• num_genes up to 1000.

These caps can be raised for a specific account on request. See Submission Parameters for the full list of supported parameters.

Credit Balance¶

Submissions also cost credits. Once your free + paid balance falls below the negative-balance cap (default $1 below zero, with tier-specific overrides), new runs paid with credits (API or website) are refused until you top up.

See Credits for how credits work and how to top up.

Platform Circuit Breaker¶

If the heavy worker queue is full across the whole platform, new submissions are rejected with a platform at capacity message. This is rare and resolves on its own once the queue drains.

Headers on Every Response¶

Every response includes:

• X-RateLimit-Limit, your per-minute cap.
• X-RateLimit-Remaining, how many requests you have left this window.
• X-RateLimit-Reset, Unix timestamp when the window resets.

What an Exceeded Limit Looks Like¶

Each cap has its own error code so your client can react differently.

A 429 rate_limited response from the per-minute throttle includes Retry-After and retry_after in the body:

HTTP/1.1 429 Too Many Requests
Retry-After: 17
Content-Type: application/json

{
  "error": {
    "code": "rate_limited",
    "message": "Rate limit exceeded. Try again in 17 seconds.",
    "details": {"retry_after": 17, "bucket": "key"}
  }
}

Other 429 / 402 / 403 responses do not have Retry-After, because waiting will not help. Read the error code and act accordingly: top up credits for insufficient_credits, wait for an in-flight job to finish for capacity_exceeded, or reduce the request size for tier_limit_exceeded.

How to Back Off the Per-Minute Rate Limit¶

Wait at least retry_after seconds, then retry. If you keep hitting the limit, switch to exponential backoff:

delay = retry_after
while True:
    response = requests.get(url, headers=headers)
    if response.status_code != 429:
        break
    body = response.json()
    delay = max(delay, body.get("error", {}).get("details", {}).get("retry_after", delay)) * 2
    time.sleep(min(delay, 300))

Cap the delay at five minutes so you do not silently stall.

Reads vs Writes¶

Reads (GET /api/v1/submissions, GET /api/v1/results) only hit the per-minute rate limit. They do not count against the daily quota, the concurrent cap, or the in-flight cap. Writes (POST /api/v1/submissions, POST /api/v1/results/{id}/continue) go through every gate above in that order.

Asking for a Higher Limit¶

Email support with the key prefix and the workload you are trying to run. We will look at your usage history and adjust if it makes sense.

Related Pages¶

• Errors and Exceptions
• Errors
• Credits
• Submissions Endpoint