> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getimg.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Rate limits

> Rate limits and retry behavior.

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.

<Note>
  Your current rate limits are shown in the [developer dashboard](https://getimg.ai/app/developer). Limits vary by account setup.
</Note>

## 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`:

```json theme={null}
{
  "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.

<CodeGroup>
  ```javascript Node.js theme={null}
  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;
    }
  }
  ```

  ```python Python theme={null}
  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
  ```

  ```bash cURL theme={null}
  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"
  ```
</CodeGroup>

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.