To ensure fair usage and platform stability, the Productboard API enforces rate limits on incoming requests.
Beta notice
Productboard REST API 2.0 is currently in Beta. Use it for experimentation, prototyping, and early integrations. Please note that individual endpoints may still change before the public release. We’re actively looking for Feedback & Help – let us know what works and what doesn’t. For critical production systems, continue using the Productboard REST API v1.0.
Limit
The default rate limit is 50 requests per second, per access token
If you exceed this limit, the API will respond with:
HTTP 429 Too Many RequestsThis means you're sending requests too quickly and need to slow down before continuing.
Rate Limit Headers
The API includes the following headers to help you track usage:
| Header | Description |
|---|---|
X-RateLimit-Limit | Maximum number of requests allowed in the current time window |
X-RateLimit-Remaining | Number of requests remaining before hitting the limit |
Retry-After | (Only when throttled) Number of seconds to wait before retrying |
Use these headers to implement smart retry logic and avoid being throttled.
Handling 429 Responses
When you receive a 429 Too Many Requests response:
- Check for the
Retry-Afterheader, which tells you how many seconds to wait - Back off and retry the request after the delay
- Avoid retrying immediately or in a tight loop
Example:
HTTP/1.1 429 Too Many Requests
Retry-After: 2In this case, wait 2 seconds before retrying.
Best Practices
- Avoid bursts: Spread requests evenly across time rather than sending them all at once
- Cache responses: Especially for read-heavy use cases, cache API results locally to avoid unnecessary requests
- Use rate limit headers: Proactively monitor usage and implement logic to pause or back off when nearing the limit
- Retry responsibly: Use exponential backoff or delay-based retries when encountering 429s