Rate limiting

To ensure the stability and reliability of our platform, we have implemented rate limiting on API endpoints. These rate limits are designed to prevent misuse and overloading of the API. Following these limits helps maintain optimal performance and availability for all users of the platform. Check out the best practices for managing rate limits.

Bob's API rate limit determines how many API calls can be made per minute. For example, thev1/people/search endpoint allows 50 requests per minute. If you exceed this limit, you'll get an HTTP status code of 429, meaning too many requests.

To learn more about the rate limits for each endpoint, click the relevant link below..

Rate limit headers

In addition to seeing your rate limit on your account page, most Bob endpoints send important information about your rate limits such as the remaining limits, in the headers of the HTTP response. These headers provide information about your current usage and remaining quota.

You can expect to see the following header fields:

• X-RateLimit-Limit: The total number of requests allowed within a specific time frame.
• X-RateLimit-Remaining: The number of requests you have left in the current rate limit window.
• X-RateLimit-Reset: The time when the rate limit window resets, given in Unix epoch time.

Check the rate limit headers when integrating with Bob empowers you to regularly monitor usage, handle limits gracefully with a retry mechanism to pause requests until the limit resets, and optimize your requests to reduce unnecessary calls to stay within limits and ensure efficient API usage.

Best practices for managing rate limits

By following some best practices, you can efficiently manage your API usage and avoid disruptions due to rate limiting.

1. Understand limits: Familiarize yourself with the rate limits for each API endpoint. Check the API documentation regularly for updates.
2. Optimize requests: Optimize your requests to minimize the number of API calls. Use bulk operations when available to reduce the frequency of requests.
3. Handle rate limit errors: Implement error handling for rate limit responses (e.g., HTTP 429 Too Many Requests) and check rate limit headers to include retry logic after the specified delay.
4. Monitor usage: Continuously monitor your API usage to ensure you stay within limits. Set up alerts to notify you when you're approaching rate limits.
5. Distribute requests: If possible, distribute your requests evenly over time rather than sending large bursts of requests.
6. Cache responses: Cache responses when possible to reduce the need for repeated requests for the same data.