The limits
| Tier | Requests / hour |
|---|---|
| Expired trial | 3 |
| Seed | 25 |
| Sprout | 50 |
| Trial / Harvest | 100 |
| Grove | 200 |
| Summit | 1,000 |
503 SERVICE_UNAVAILABLE rather than allowed through unmetered.
Headers on every response
Every response (success or 429) carries the current window state:| Header | Type | Meaning |
|---|---|---|
X-RateLimit-Limit | integer | Total requests allowed in the current window |
X-RateLimit-Remaining | integer | Requests remaining before the limit kicks in |
X-RateLimit-Reset | ISO 8601 timestamp (UTC) | When the sliding window opens again |
X-RateLimit-Resetis an ISO 8601 string, not a Unix timestamp. Parse withnew Date(header)ordatetime.fromisoformat(header.replace('Z', '+00:00')).
When you hit the limit
Retry-After header is included as seconds-until-reset for clients that prefer the standard HTTP signal.
Backoff strategy
Wait untilX-RateLimit-Reset before the next attempt. Exponential backoff with jitter is the right pattern for transient 5xx errors, but for 429 you have the exact reset time — use it.
Pre-flight checks
You don’t need to hit a 429 to know you’re close to the limit. InspectX-RateLimit-Remaining on every response and throttle proactively:
What the limits are NOT
- Not per-key. Two keys owned by the same user share the same window. Splitting traffic across multiple keys does not multiply your budget.
- Not per-endpoint. All requests count against the same per-user bucket, regardless of which route they hit.
- Not per-IP. They’re scoped to the API key’s owning user.
Need a higher limit?
The standard tier limits are sized for typical integration patterns. If your application needs sustained throughput beyond Summit’s 1,000 req/hr, contact support@wiseyield.co — custom limits are available for enterprise integrations.See also
- Subscription tiers — how rate limits scale with tier
- Errors & status codes — the canonical 429 response shape