Rate Limits
The Data API enforces rate limits to ensure fair usage across all users and prevent abuse. Rate limits are calculated using a 30-second window, and are applied separately across read and write endpoints.
Structure
| Operation | Rate Limit | Window |
|---|---|---|
| Read | 600 requests | 30s |
| Write | 300 requests | 30s |
Read operations
Read operations include any API endpoints that retrieve data (GET requests). These are limited to 600 requests per 30 seconds.
Write operations
Write operations include any API endpoints which create or modify resources. These are limited to 300 requests per 30 seconds.
Rate limit response
When you exceed the rate limit, the API will respond with HTTP code 429 ("Too many requests").
Best practices
To effectively use the Data API without crossing these rate limits, implement the following best practices:
Cache Responses
Cache frequently accessed data locally to reduce unnecessary API calls. You should:
- Store query results with appropriate TTLs based on your use case
- Only re-fetch data when your cache expires or when real-time updates are required
Monitor Usage
All API responses include the following HTTP headers to help you stay within limits:
| Header | Type | Description |
|---|---|---|
X-RATELIMIT-LIMIT | numeric | The API rate limit cap for this type of request |
X-RATELIMIT-REMAINING | numeric | The number of requests remaining before rate-limiting is enforced |
X-RATELIMIT-RESET | numeric | The number of seconds remaining in the rate-limit window |
Use these headers to track your usage and implement backoff strategies when approaching limits.
Support
If you are building an application that uses Rebar Data or consistently hitting rate limits, please reach out to us on Discord to discuss your needs.