Rate limits

Rate limits are applied per workspace and affect generation endpoints. Plan for them early if you’re sending generations at scale.

Types of rate limits

There are three independent rate limits, all enforced on generation requests only:

Limit	Applies to	Window	Description
Image RPM	`POST /v2/images/generations`	60 seconds	Maximum image generation submissions per minute
Video RPM	`POST /v2/videos/generations`	60 seconds	Maximum video generation submissions per minute
Concurrent requests	Both generation endpoints	Rolling	Maximum in-flight generation requests at any time

Image and video RPM are tracked separately. The concurrent requests limit is shared across both.

Your current rate limits are shown in the developer dashboard. Limits vary by account setup.

How this affects image and video generation

Image generations count when you submit the generation.
Video generations count when you submit the generation.
Polling GET /v2/videos/generations/{id} is a read operation. It does not create a new generation.
Pending video generations can still count against your concurrent limit until they finish.

Rate limit headers

Every generation response includes headers so you can track your usage:

Header	Description
`X-RateLimit-Limit`	Maximum requests allowed in the current window
`X-RateLimit-Remaining`	Requests remaining in the current window
`X-RateLimit-Reset`	Unix timestamp in seconds when the window resets

When you exceed the RPM limit, the API returns HTTP 429 with an additional header:

Header	Description
`Retry-After`	Seconds to wait before retrying

Concurrent request limit

The concurrent limit caps in-flight generation requests across both endpoints. Pending video generations count against this limit. When exceeded, the API returns 429:

{
  "error": {
    "message": "Too many concurrent requests. Please wait for current requests to finish.",
    "code": "rate_limit"
  }
}

Handling rate limits

Use the Retry-After header with exponential backoff.

import GetimgAI from "getimg-ai";

const client = new GetimgAI({ maxRetries: 5 });

async function generate(payload) {
  try {
    return await client.images.generate(payload);
  } catch (err) {
    if (err instanceof GetimgAI.RateLimitError) {
      console.error("Rate limit exceeded after retries");
    }
    throw err;
  }
}

import getimg
from getimg import GetimgAI

client = GetimgAI(max_retries=5)

def generate(**payload):
    try:
        return client.images.generate(**payload)
    except getimg.RateLimitError:
        print("Rate limit exceeded after retries")
        raise

response_headers=$(mktemp)

curl -X POST https://api.getimg.ai/v2/images/generations \
  -D "$response_headers" \
  -H "Authorization: Bearer $GETIMG_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "seedream-5-lite",
    "prompt": "A cinematic portrait of a cat astronaut"
  }'

retry_after=$(grep -i '^Retry-After:' "$response_headers" | awk '{print $2}' | tr -d '\r')
if [ -n "$retry_after" ]; then
  echo "Retry after ${retry_after}s"
fi

rm "$response_headers"

If you run your own queue, back off new generation submissions when remaining capacity is low. Keep polling separate from submission throughput control so retries do not crowd out new work.

Getting started

Generation

Concepts

Types of rate limits

How this affects image and video generation

Rate limit headers

Concurrent request limit

Handling rate limits

​Types of rate limits

​How this affects image and video generation

​Rate limit headers

​Concurrent request limit

​Handling rate limits

Types of rate limits

How this affects image and video generation

Rate limit headers

Concurrent request limit

Handling rate limits