Overview

Rate limiting is a technique used to control the number of API requests a client can make to a server within a specific period of time. It helps prevent abuse, ensures fair usage and protects our backend systems from being overwhelmed.

• Ensure fair access for all users
• Protect system stability and performance
• Protects system resources and improves scalability
• Avoids unexpected outages
   

The Class platform enforces a rate limit of 500 endpoint calls per minute per OAuth client. 
This ensures fair usage and system stability across all clients. Should you exceed this limit, your API calls will received a 429 response.

Rate limit response headers

Handling 429 response

When your application—identified by its OAuth client—receives a 429 Too Many Requests response, it means it has temporarily exceeded the allowed request volume within the specified timeframe. At this point, it’s essential that your application immediately stops making further requests.

Upon receiving a 429 response, your application should check for the X-RateLimit-ResetAfter header. This header indicates how many seconds your application must wait before sending another request. Your application must always respect this header.

By honouring the X-RateLimit-ResetAfter header, your application gracefully backs off, allowing the rate limit window to reset and helping prevent unnecessary strain on our systems.

Rate limiting for serverless technologies

With the rise of modern serverless technologies—such as AWS Lambda—API traffic is no longer tied to a single IP address, instead requests may originate from a wide range of dynamic sources. This article explains how to structure your AWS Lambda functions to stay within this limit while efficiently processing fund-related data.

• Invoked an endpoint to retrieve a list of all "Active" funds.
• Then, for each fund, call additional endpoints to fetch specific data (e.g., transactions, Investment related data, member contributions).

When working with fund-related data, it's common for each fund to trigger multiple API calls—typically between 5 to 7 calls per fund depending on the business use case(s). To stay within the 500 calls per minute limit, it's important to queue your requests and structure your processing logic accordingly. We suggest queuing calls per fund and not to exceed having more than 10 concurrent queues active at any one time.  Some businesses has large number of funds and not queueing could lead to a high volume of API calls and subsequently being rate limited. 
 

Rate Limit Strategy

To avoid exceeding the 500 calls/minute limit, we recommend:

• Queue Fund Processing: Group a small number of funds (e.g. 3–4) and process them together. This helps you control the total number of API calls per queque.   (Note: A batch can be one fund, or a few funds depending on your use case)
• Limit Concurrency: Ensure that no more than a few queues are processed at the same time. This prevents spikes in traffic that could breach the rate limit.
• Queue Responsibly: While you may not use a formal queuing system, design your logic to wait for one batch to complete before starting the next.
• Factor in Retries: Retries due to errors or timeouts can increase your call volume. Always include a buffer in your calculations to account for this.
• Adjust for Fund Complexity: Some funds may require more data and therefore more API calls. Dynamically adjust your batch size based on the expected call volume per fund.

By following these principles, you can ensure your integration remains compliant with our platform’s rate limits while still delivering reliable and scalable performance. This ensures that even under high load, your integration remains compliant with our rate limits.

What's Next?

For more guidance, refer to AWS’s official documentation on AWS Lambda function.