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:

HeaderValue
X-RateLimit-LimitMaximum requests per minute.
X-RateLimit-RemainingRequests 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:

HeaderValue
Retry-AfterSeconds until you may send again.
X-RateLimit-ResetUnix 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

  1. Check X-RateLimit-Remaining on every response and slow down before you hit 0.
  2. On 429, wait for the duration in Retry-After (seconds) before retrying. Send Accept: application/json: without it the 429 comes as an HTML page (with the same headers).
  3. For burst traffic, batch requests — e.g. paginate with per_page=50 instead of per_page=10.