Rate Limiting
The Monotree Open API enforces 60 requests per minute per token by default. The limit is configurable per server — your account team can raise it for high-volume integrations.
Incoming webhooks have no token, so their requests are counted per sending IP address instead.
Requests the MCP server's call_open_api tool makes are counted per signed-in user instead: each call runs on a new short-lived token, so all of one user's call_open_api requests share one bucket of the same size.
Headers
Every request the token is accepted for carries:
| Header | Value |
|---|---|
X-RateLimit-Limit | Maximum requests per minute. |
X-RateLimit-Remaining | Requests remaining in the current window. |
A request refused for its token (401, or the IP-restriction 403) is not counted and carries no rate limit headers.
When the limit is exceeded, the response is 429 Too Many Requests, which also carries:
| Header | Value |
|---|---|
Retry-After | Seconds until you may send again. |
X-RateLimit-Reset | Unix timestamp when the window resets. |
HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
Retry-After: 23
X-RateLimit-Reset: 1790254823
Content-Type: application/json
{
"title": "ThrottleRequestsException",
"message": "Too Many Attempts.",
"status": 429,
"code": 0
}Backoff strategy
- Check
X-RateLimit-Remainingon every response and slow down before you hit0. - On
429, wait for the duration inRetry-After(seconds) before retrying. SendAccept: application/json: without it the 429 comes as an HTML page (with the same headers). - For burst traffic, batch requests — e.g. paginate with
per_page=50instead ofper_page=10.