Rate Limiting and Throttling

GoodData APIs use rate limiting, also called API throttling, to ensure platform stability and protect backend services and shared resources. Rate limits are designed to accommodate normal usage patterns while preventing excessive requests that could impact service availability for all users.

This page explains how rate limits work, how to handle throttled requests, and which public limits currently apply to selected API endpoints.

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.

The GoodData Python SDK automatically handles throttled requests for supported API calls. When the API returns 429 Too Many Requests, the SDK respects the Retry-After header and retries the request according to its retry configuration.

Response Headers

When making requests to our API, the following rate limit headers are included in responses to help you track your usage:

Multiple Rate Limit Levels

Our system implements multiple rate limit levels including:

• user-based limits
• organization-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.

For selected public endpoints, GoodData publishes request-per-minute limits. These limits are applied per user and per organization. The user-level limit applies to requests made by a specific authenticated user. The organization-level limit acts as a broader traffic safeguard for aggregate requests from the same organization.

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."
}

Public Rate Limits

The following public limits apply to selected high-impact API endpoints. These limits are expressed in requests per minute and are applied per user and per organization.

The limits are currently the same across all regions. They may be adjusted over time as we continue monitoring platform usage and performance.

Python SDK Retry Handling

The GoodData Python SDK (version 1.67 and newer) includes built-in retry handling for throttled requests. If the API returns 429 Too Many Requests, the SDK retries the request automatically.

By default, the SDK uses the following retry behavior:

• retries requests that receive 429 Too Many Requests
• honors the Retry-After header when the API returns it
• uses exponential backoff when Retry-After is not present
• retries up to 10 times
• uses backoff_factor=0.5 and backoff_max=60s
• applies retry handling to GET, HEAD, OPTIONS, TRACE, POST, PUT, PATCH, and DELETE requests

Retry handling is available through GoodDataApiClientRetryConfig, which can be imported from gooddata_sdk and passed to GoodDataApiClient or GoodDataSdk.create.

from gooddata_sdk import GoodDataSdk, GoodDataApiClientRetryConfig

retry_config = GoodDataApiClientRetryConfig(
    total=10,
    backoff_factor=0.5,
    backoff_max=60,
)

sdk = GoodDataSdk.create(
    host_="https://<your-gooddata-host>",
    token_="<your-api-token>",
    retry_config=retry_config,
)

The retry behavior is especially useful for automation, bulk provisioning, and layout import workflows that may occasionally reach public rate limits.

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.

Some specific rate limit numbers are published for selected endpoints in the Public Rate Limits table. For endpoints that are not listed there, specific limits are not published because:

• Limits may vary between different datacenters and regions in the future
• 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

Some endpoints are limited because they are resource-intensive by design and are not intended to be called at high frequency, for example layout import APIs.

The limits are designed to be transparent while protecting the platform from excessive or abusive usage patterns.

For best results, integrations that perform automation, bulk provisioning, or repeated layout imports should pace requests, monitor rate limit headers, and handle 429 Too Many Requests responses gracefully.

API Throttling

API throttling is the enforcement of rate limits. When throttling occurs, the API returns 429 Too Many Requests and includes rate limit headers that help you determine when to retry the request.

To handle throttling correctly:

• use built-in retry handling in the GoodData Python SDK when possible
• wait for the time specified in the Retry-After header
• retry with exponential backoff if Retry-After is not present
• avoid retrying immediately in a tight loop
• reduce request bursts by spreading calls over time

This behavior helps protect platform stability and keeps API access reliable for all customers.

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.