Rate Limiting
Our API implements rate limiting to ensure GoodData Cloud’s stability and protect our backend services. Rate limits are designed to accommodate normal usage patterns while preventing excessive requests that could impact service availability for all users.
Rate Limit Strategy
We use a fixed window rate limiting strategy. When you exceed the rate limit, you’ll receive a 429 Too Many Requests response as defined in the RFC-6585 standard.
Response Headers
When making requests to our API, the following rate limit headers are included in responses to help you track your usage:
| Header | Description |
|---|---|
Retry-After | Number of seconds to wait before making a follow-up request (only present when rate limit is exceeded). See MDN documentation for details |
X-RateLimit-Limit | Maximum number of requests allowed within the current time window |
X-RateLimit-Remaining | Number of requests remaining in the current time window |
X-RateLimit-Reset | Number of seconds until the time window resets |
Multiple Rate Limit Levels
Our system implements multiple rate limit levels including:
- IP-based limits
- Path-specific limits
- Backend service limits
When multiple rate limits apply to a request, the most restrictive limit is reflected in the response headers.
Rate Limit Response
When you exceed the rate limit, you’ll receive:
HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 3600
Retry-After: 3600
Content-Type: application/json
{
"error": "Too Many Requests",
"message": "Rate limit exceeded. Please retry after the specified time."
}
Best Practices
Following these API best practices will help you avoid hitting rate limits:
- Implement exponential backoff when receiving 429 responses
- Respect the Retry-After header to avoid unnecessary requests
- Cache responses when possible to reduce redundant API calls
- Batch operations where supported to minimize the number of requests
- Monitor the rate limit headers to track your usage proactively
- Distribute requests evenly over time rather than sending bursts
Rate Limit Configuration
Our rate limits are configured based on extensive monitoring of actual usage patterns to ensure they accommodate normal API usage without disruption. The limits are set well above typical usage thresholds, meaning that clients following API best practices should not encounter them during regular operations.
We don’t publish specific rate limit numbers because:
- Limits may vary between different datacenters and regions
- Different endpoints may have different limits based on their resource requirements
- Limits are dynamically adjusted based on system capacity and performance metrics
- We reserve the right to adjust limits to maintain optimal platform performance
Rest assured, the limits are designed to be transparent to well-behaved clients while protecting the platform from excessive or abusive usage patterns.
Need Higher Limits?
If you believe you’ve reached rate limits despite following best practices and have a valid use case requiring higher limits, please contact our support team with:
- Your use case description
- Current request patterns
- Expected request volume
- Any relevant technical details
Our support team will review your requirements and work with you to find an appropriate solution.
Contact Support
For rate limit inquiries or assistance, please reach out to our support team through your preferred support channel.