API Credits & Rate Limits
In our API, each call to an endpoint typically consumes one API credit. However, an important exception exists for bulk endpoints.
Bulk Endpoints and API Credits
Bulk endpoints allow users to retrieve data for multiple parameter combinations in a single request. While this is efficient in terms of reducing the number of API calls, it's essential to understand how API credits are consumed:
Credit Calculation: Each request to a bulk endpoint consumes as many API credits as individual calls to the standard endpoint would. For example:
Calling the
/market/mvrv/bulkendpoint with 5 assets will consume 5 API credits.If a bulk request includes 5 assets and 5 exchanges, it will consume 25 API credits (one for each combination's metric value).
Parameter Whitelists: When parameters are not specified (i.e., no whitelists are applied), the bulk endpoint returns data for all possible parameter values. This can lead to a significant number of API credits being consumed. To manage and predict credit usage effectively, it's advisable to:
For more detailed information on bulk endpoints and their usage, refer to the Bulk Metrics documentation.
Rate Limits
Rate limits are applied to all API requests to ensure stability and fair usage. If you exceed the rate limit, the API will return a 429 Too Many Requests error.
To increase your rate limit, please contact your account manager.
General Limits
Standard Requests: Defaults to 600 req/min, or varies based on your specific access tier.
Metadata Endpoints: Separately limited to 1200 req/min. This bucket is fully isolated and does not impact your standard request quota.
Studio: Requests made via Glassnode Studio from the same account do consume your API rate limit as well. Studio may request multiple metrics (e.g. on a dashboard) as well as call metadata endpoints.
Response Headers
Every API response includes headers to help you track your usage:
x-rate-limit-limit
The total request limit per minute (e.g., 600).
x-rate-limit-remaining
The number of requests left in the current window (e.g., 599).
x-rate-limit-reset
Time in seconds until the limit resets (e.g., 60).
Best Practices & Common Pitfalls
1. High Cardinality Requests (Assets/Exchanges) Running into limits when requesting many parameter combinations (e.g., iterating through a list of assets) is a common issue.
Solution: Use Bulk Endpoints. These allow you to fetch data for multiple parameters (like "all assets" or "all exchanges") in a single request.
2. Looping Through Metrics Scripts that loop through numerous metrics often trigger rate limits.
Solution: Pass the
x-rate-limitheaders to your HTTP client library. Many modern libraries can read these headers to automatically pace requests and respect the reset window. Otherwise, you can implement a delay that adheres to the rate limit.
Last updated