specification: API Commons Rate Limits specificationVersion: '0.1' provider: StayingAPI providerId: stayingapi generated: '2026-08-09' method: searched created: '2026-08-09' modified: '2026-08-09' tags: - Rate Limiting - Travel - Accommodation Data description: >- StayingAPI publishes a per-plan request-rate limit in requests per minute, enforced per-key for REST and on a separate per-user bucket for the MCP server. It is a token bucket: exhaustion returns 429 rate_limit_exceeded with Retry-After. The rate limit is the second of two independent throttles — the first is the credit balance, which meters work rather than request frequency. sources: - https://stayingapi.com/pricing - https://stayingapi.com/docs/conventions headers: limit: X-RateLimit-Limit remaining: X-RateLimit-Remaining reset: X-RateLimit-Reset retryAfter: Retry-After requestId: X-Request-Id responseCodes: throttled: 429 errorCodes: throttled: rate_limit_exceeded scopes: rest: per API key mcp: per user (separate bucket from REST) limits: - name: Free / Sandbox plan: free scope: key metric: requests_per_minute limit: 30 timeFrame: minute - name: Starter plan: starter scope: key metric: requests_per_minute limit: 60 timeFrame: minute - name: Pro plan: pro scope: key metric: requests_per_minute limit: 120 timeFrame: minute - name: Scale plan: scale scope: key metric: requests_per_minute limit: 300 timeFrame: minute - name: Enterprise plan: enterprise scope: key metric: requests_per_minute limit: -1 timeFrame: minute note: Custom — not published. introspection: operation: GET /v1/account field: data.rateLimit.requestsPerMinute cost: 0 credits guidance: >- Honour Retry-After and back off with jitter; the official SDK does this automatically. A tight polling loop on GET /v1/jobs/{jobId} is the documented way developers hit the limit. x-evidence: - url: https://stayingapi.com/pricing http_status: 200 - url: https://stayingapi.com/docs/conventions http_status: 200