Skip to main content
Rate limits bound how fast you call. Credits bound how much you call in a month. They are enforced separately.

​
The limits

Per API key, on a fixed 60-second window.

​
What counts

Every authenticated request takes a slot, whether or not it runs a tool:
  • REST — POST /v1/tool/{slug}, and the reads too: GET /v1/tools/list, GET /v1/tools/search, GET /v1/tool/{slug}, GET /v1/me/credits, GET /v1/me/usage. The reads cost no credits, but they do cost a slot.
  • MCP — every JSON-RPC message you POST to the hosted endpoint, including the initialize and tools/list a client sends when it connects. A session therefore starts a couple of slots down before your agent calls anything. search_tools, describe_tool, get_credits and get_usage count too, even though they cost no credits — so the search → describe → run sequence is three slots, not one.
Only requests we can attribute to your key count, so an unknown slug (404) and an unauthenticated request (401) do not. Neither does a non-POST request to the MCP endpoint (405) — some clients probe it for a stream we don’t serve, and that shouldn’t cost you anything.

​
Hitting one

The response carries a Retry-After header as well as retry_after in the body. Use it — a fixed backoff either wastes time or hammers the window.
A 429 costs no credits — it is refunded like any other failure.

​
Concurrent file conversions

File conversions (PDF, Office, background removal) run as background jobs, so they are additionally capped on how many you can have in flight at once: Exceeding it returns too_many_jobs (429). Credits are unaffected, and a finished or abandoned job frees its slot automatically.

​
Being a good client

  • Honour Retry-After. It is the actual remaining window.
  • Retry 429 and 5xx; do not retry 4xx. A validation_error will fail identically forever.
  • Sequential is usually enough. At 60 req/min, a serial loop with no delay is already near the limit.