Rate limiting

The Public API enforces a sliding-window rate limit on every authenticated request. The bucket is shared with the MCP server — calls from both transports count against the same quota.

Headers on every response

X-RateLimit-Limit: 120
X-RateLimit-Remaining: 117
X-RateLimit-Reset: 1717000060

• X-RateLimit-Limit — total quota for the current window (always 120).
• X-RateLimit-Remaining — requests left until reset.
• X-RateLimit-Reset — Unix timestamp (seconds) when the window resets.

When you exceed the limit

The API returns 429 RATE_LIMITED with a Retry-After header (seconds). Back off until then before retrying — exponential backoff is unnecessary because the window is fixed.

HTTP/1.1 429 Too Many Requests
Retry-After: 38
X-RateLimit-Limit: 120
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1717000038

{
  "error": {
    "code": "RATE_LIMITED",
    "message": "Rate limit exceeded. Slow down or wait for the window to reset.",
    "request_id": "01HZ8..."
  }
}

Best practices

• Read X-RateLimit-Remaining and slow down before you hit zero.
• For batch work (re-indexing keywords, exporting reviews), pace your requests at ~2/second.
• Cache idempotent reads on your side (projects, listings) for at least 60s.
• Run jobs serially when possible — async endpoints (simulations, localize) count as a single request each.