Rate Limit

At Railz, we've implemented rate limiting to ensure fair and efficient usage of our Railz API. Rate limiting restricts the number of requests that can be made to the API within a defined time period. This mechanism helps maintain the quality of service, prevent abuse, and ensure optimal performance for all users.

Why Rate Limits?

The primary goals of rate limits in the Railz API are to:

• Ensure Reliability: By controlling the rate at which requests can be made, we prevent server overload and maintain the reliability and responsiveness of our API.

• Fair Usage: Rate limits ensure that no single user or application monopolizes the available resources, promoting fair usage among all consumers of the Railz API.

• Abuse Prevention: Rate limits act as a safeguard against potential malicious activity or unintentional excessive usage, enhancing the overall security of our platform.

Rate Limits

For the Railz API, the following rate limits are applied:

• 1,000 Requests per Minute: This limit is set for each unique combination of Team and Sandbox allowing a combined total of 1,000 requests per minute.

🚧

Upcoming Rate Limit Features

In the near future , we'll introduce the ability to handle up to 20 requests simultaneously.

Rate Limits per Accounting Service Provider

The following table provides details on the rate limits for each accounting service provider:

ℹ️

It is important to note that these rate limits can vary based on the client's subscription plan with the respective accounting service provider (ASP). Clients with different plans may experience different rate limits.

Successful Request

When a request is successful, the API response will include the following headers:

• X-RateLimit-Limit: The total rate limit allowed for the specified combination.
• X-RateLimit-Remaining: The number of remaining requests before hitting the rate limit.
• X-RateLimit-Reset: The time in seconds until the rate limit counter resets.

Throttled Request

In the event that the rate limit is reached, the API will respond with an HTTP status code 429 Too Many Requests. Additionally, the following header will be provided:

• Retry-After: The duration in seconds until the throttling period ends, indicating when a new request can be retried.

🚧

Remember that throttled requests are temporary, and you should wait until the Retry-After duration has elapsed before attempting to make a new request.

Mitigating Rate Limits

To mitigate rate limiting, consider implementing Exponential Backoff in your retry strategy. Exponential Backoff is a technique where you progressively increase the time between retry attempts, which can help ease the load on the API and improve the chances of successful requests.

Exponential Backoff Examples

Here's how you can implement Exponential Backoff using popular libraries:

import backoff
import requests

@backoff.on_exception(
    backoff.expo,
    requests.exceptions.RequestException,
    max_time=60,
    max_tries=5
)
def make_api_request():
    # Your API request logic here
    pass

Node.js (Using node-fetch and p-retry)

import pRetry, {AbortError} from 'p-retry';
import fetch from 'node-fetch';

const run = async () => {
	const response = await fetch('<API_URL>');

	// Abort retrying if error is not 429
	if (response.status !== 429) {
		throw new AbortError(response.statusText);
	}

	return response;
};

await pRetry(run, {retries: 5})