API reference·3 min read

Rate limits

How rate limiting works, what triggers a 429, and how to design your integration to stay clear of the limit.

By Operelio team · Updated July 2026

On this page6
  1. 1.Current limit
  2. 2.How the window works
  3. 3.Concurrent job limit
  4. 4.What happens when you hit the limit
  5. 5.Best practices
  6. 6.Frequently asked questions

Current limit

Two limits apply on the Team and Agency plans. A monthly cap on total calls (Team 1,000 calls per month, Agency 5,000), and a burst limit of 60 requests per minute per API key. Each key has its own per-minute window. Separate keys don't share or compete on the burst limit, but all of a workspace's calls count toward the one monthly cap.

The monthly cap counts every call to a /api/v1/* endpoint and resets on your billing cycle anniversary. Hitting it returns 429 with the machine-readable code "api_monthly_limit_reached" plus limit, used, and resetAt fields in the body. This 429 also carries a Retry-After header, but it counts down to your cycle reset, so it can be days. Treat it as a stop signal, not a sleep timer.

How the window works

Your first request opens a 60-second window. You can make up to 60 requests inside that window. Request 61 returns 429 with a Retry-After header.

When the window expires, the next request opens a fresh one. Stay under 60 calls per minute and you won't see a 429.

Concurrent job limit

Separate from the rate limit, your plan also caps how many jobs can be running at once: 1 on Free, 2 on Pro, 3 on Team, 5 on Agency. POST /jobs returns 429 (with no Retry-After) if you'd exceed it, with the error mentioning "jobs running".

POST /jobs/batch is not gated by the concurrent limit at submission time. A 50-file batch creates 50 jobs all at once; the worker pulls them off the queue serially in upload order. So you can submit batches without worrying about the concurrent cap, but the cap still applies to any individual /jobs calls you make alongside.

What happens when you hit the limit

Requests over 60 in a single window return HTTP 429 (Too Many Requests) with a Retry-After header and the error "Rate limit exceeded". The Retry-After value is the number of seconds until the current window closes and a new one can open.

Example 429 response
HTTP/1.1 429 Too Many Requests
Retry-After: 23
Content-Type: application/json

{ "error": "Rate limit exceeded" }

Two other 429s exist. POST /jobs returns 429 when your monthly job quota is exhausted, with the error "Monthly job limit reached" and no Retry-After header. Any endpoint returns 429 with code "api_monthly_limit_reached" when the monthly API call cap is spent; that one has a Retry-After, but it counts down to your cycle reset. Switch on the error string and the code field to tell the cases apart, not on Retry-After alone.

Best practices

Wait at least 2 seconds between status polls. Most jobs finish in under 10 seconds, so a 2-second interval keeps you well clear of the limit while still feeling responsive.

Use POST /jobs/batch when you have multiple files for the same tool. One batch request counts as one API call regardless of file count, so a 50-file batch is far more efficient than 50 individual /jobs calls.

Honor Retry-After when you do hit a 429. Sleep for that many seconds before retrying, rather than retrying in a tight loop and burning the next window too.

If you need higher throughput, contact support to discuss enterprise options.

Frequently asked questions

Does the rate limit apply per key or per account?

The burst limit is per key. If you have separate keys for production and testing, each gets its own 60-per-minute window. They don't share or compete. The monthly call cap is per workspace, so every key's calls draw from the same monthly pool.

What counts as one request?

Every HTTP call to a /api/v1/* endpoint counts as one. POST /jobs/batch counts as one even when it processes 50 files. Polling GET /jobs/:id once is one request, so a 2-second poll interval is recommended over a tight loop.

Can I burst above 60 right at the boundary of a window?

Yes, briefly. Because each window starts on your first request, you could send 60 requests near the end of one window and another 60 just after the next opens. Don't design around it. Keep your cadence under 60 calls per minute and you won't see 429s.

Ready to get started?

Upload a file and run your first transformation. Free, no credit card required.