Rate Limits
The Shield API enforces rate limits to ensure fair usage to 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 |
Write operations
Write operations include any API endpoints which create or modify resources (like sending a transaction). These are limited to 300 requests per 30 seconds.
Read operations
Read operations include any API endpoints that retrieve data (GET requests). These are limited to 600 requests per 30 seconds.
Rate limit response
When you exceed the rate limit, the API will respond with the HTTP code 429("Too many requests).
Best practices
To effectively use the Shield API without crossing these rate limits, implement the following best practices:
Cache Responses
Transaction fees are recalculated each time a block is mined, and reduces unnecessary load on the Shield server and your software. You should:
- Store the current Shield fees locally.
- Only re-fetch fees after a block has been mined or if a block has recently been mined but the fee response was not updated.
Monitor Usage
Given the rate limiting enforced on the Shield API, you should monitor your API usage to stay within limits. All API responses include the following HTTP headers to facilitate this:
| 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. |
TODO
Support
If you are building an application that uses Rebar Shield or consistently hitting rate limits, please reach out to us on Discord to discuss your needs.