Skip to main content
The FirstQuadrant API implements rate limiting to ensure fair usage and maintain service reliability for all users. This guide explains our rate limits and how to handle them gracefully.

Current rate limits

Authentication endpoints

Authentication endpoints have stricter rate limits for security:

Standard API endpoints

Currently, standard API endpoints do not have publicly-available rate limits. We recommend implementing rate limit handling in your code to ensure compatibility with future updates.

Rate limit response

When you exceed the rate limit, you’ll receive a 429 Too Many Requests response:

Handling rate limits

Exponential backoff

The recommended approach is to implement exponential backoff with jitter:

Best practices

1. Implement retry logic

Always implement retry logic with exponential backoff:

2. Queue requests

For high-volume applications, implement a request queue:

3. Monitor rate limit usage

Track your API usage to avoid hitting limits:

4. Batch operations

Reduce API calls by batching operations where possible:

5. Cache responses

Implement caching to reduce redundant API calls:

Error recovery strategies

Circuit breaker pattern

Implement a circuit breaker to prevent cascading failures:

Testing rate limits

When developing, test your rate limit handling:

Future considerations

While most endpoints currently don’t have publicly-available rate limits, this may change. Design your integration to:
  1. Handle 429 responses gracefully even on endpoints without current limits
  2. Monitor response headers for future rate limit information
  3. Implement configurable delays between requests
  4. Use pagination to reduce the number of requests
  5. Cache data where appropriate
By following these practices, your integration will continue to work smoothly as the API evolves.