Rate limits

The service limits how many requests it accepts in a short time, so one busy script or one workspace cannot slow everyone else down. Ordinary use stays far below the limits. When a limit is reached, the app shows Too many requests. Wait a moment and try again. A script that uses the API gets a "Too Many Requests" answer that says when to try again.

What a refusal looks like

A script that calls the API gets this answer:

HTTP/1.1 429 Too Many Requests
Retry-After: 37
RateLimit-Limit: 300
RateLimit-Remaining: 0
RateLimit-Reset: 37

{ "statusCode": 429, "error": "Too Many Requests", "message": "Rate limit exceeded (tenant); retry after 37 s", "retryAfterSeconds": 37 }

Wait Retry-After seconds, then send the request again. Every answer carries RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset (seconds until the window resets), so a script can slow down before it is refused.

The limits

There are three kinds of limit. A request has to pass all that apply.

1. Per address, before anything else: 300 requests a minute from one IP address, on every request except the service's health check.
2. Per workspace, by the kind of request. Everyone in a workspace shares its budget, and other workspaces have their own.
3. Per route, for a few requests with a limit of their own, such as the request form on the public website (5 a minute from one address).

Larger plans get more room: the Organization plan doubles every workspace limit, and Enterprise multiplies it by four. Requests without a workspace (signing in for the first time, creating a workspace) are counted per person.