Core concepts

Rate limits

The API limits the number of requests per minute and the number of generations launched per minute and per hour. The limits of an organization depend on its tier (see Pricing).

Requests per minute

  • Per organization: the value of the “Requests/min” column of the tiers, shared by all the organization's keys, test and live. Each message sent to the MCP server counts as one request; an MCP client sends three or four before its first tool call.
  • Per IP address: 600 requests per minute, counted before the key is checked, unauthenticated requests included.
  • The counter covers a one-minute window, opened by the first request, and restarts from zero with the next window.
  • Beyond that, the API responds 429 rate_limit_exceeded, with the delay in seconds in the Retry-After header.
Every response to an authenticated request includes these headers:
HeaderDescriptionExample
x-ratelimit-limit-requestsRequests allowed per minute30
x-ratelimit-remaining-requestsRequests left in the window27
x-ratelimit-reset-requestsTime until the next window42s

Generations launched

  • The quota depends on the tier (“Generations/min” and “Generations/h” columns of the tiers) and is counted over a sliding minute and a sliding hour. Test mode and live mode each have their own quota.
  • A generation counts from its acceptance, even if it then fails or is canceled. A request refused at admission (invalid parameter, moderation, balance, monthly limit, heavy load) does not count.
  • /v1, the MCP server and the console playground share this quota.
  • Beyond that, the API responds 429 generation_rate_limit_exceeded, with in Retry-After the delay in seconds before a generation can be launched. Nothing is created or charged.
  • The number of generations in progress at once is not limited.
Every response to an accepted creation includes these headers:
HeaderDescriptionExample
x-ratelimit-limit-generations-minuteGenerations allowed per minute5
x-ratelimit-remaining-generations-minuteLeft over the last minute, this one included4
x-ratelimit-limit-generations-hourGenerations allowed per hour50
x-ratelimit-remaining-generations-hourLeft over the last hour, this one included37

Heavy load

Under heavy load, a live mode render, edit or decoration request can be refused at admission, whatever the organization's limits. The API then responds 503 overloaded, with a Retry-After header of 30 to 300 seconds. Nothing is charged.

Good practices

  • Slow down before x-ratelimit-remaining-requests or x-ratelimit-remaining-generations-minute reaches zero.
  • To wait for a generation to end, prefer a synchronous creation or a webhook to repeated reads.
  • Cache the styles and edit materials: one read a day is enough.
curl -i https://api.renderthink.com/v1/styles \
  -H "Authorization: Bearer $RENDERTHINK_API_KEY"
# HTTP/1.1 429 Too Many Requests
# Retry-After: 18