Rate limits
Rate limits regulate the number of requests you can make to the Bayut API within a given timeframe. These limits help maintain fair usage, protect against abuse, and help maintain system performance for all users.
Rate limits tier
Your app's requests to the Profolio API are evaluated per token. Rate limit windows are per minute.
| Request Type | Limit | Window |
|---|---|---|
Authenticated API requests | 60 requests | 1 minute |
Because rate limits depend on a variety of factors and are subject to change, rate limits should not be hard coded into your app. Instead, your app should parse response headers to prevent hitting the limit, and to respond accordingly in case you do.
Header Format
For most API requests made, we return optional HTTP response headers containing the rate limit encountered during your request.
| Header | Description |
|---|---|
X-RateLimit-Limit | Total number of allowed requests within the current window. |
X-RateLimit-Remaining | Number of remaining requests available before the limit resets. |
Example
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 58Exceeding the Rate Limit
In the case that a rate limit is exceeded, the API will return a HTTP 429 response code with a JSON body. Your application should rely on the retry_after field to determine when to retry the request.
Example
< HTTP/1.1 429 TOO MANY REQUESTS
< Content-Type: application/json
{
"error": "Rate limit exceeded",
"message": "Rate limit exceeded",
"retry_after": 60
}Best Practices
- Use response headers to monitor and adapt to rate limits.
- Implement exponential backoff or queueing for retries.
- Distribute requests efficiently to avoid bursts.
- Cache API responses whenever possible to minimize unnecessary requests.