We have implemented request rate limits to our backend APIs to further improve our backend performance, and protect against malicious actors from denying backend service to our customers. This notice describes our implementation of rate limiting, and describes when rate limits will be enabled for your app.
What are request rate limits?
Rate limits restrict the number of successful requests against an API endpoint when the endpoint is abused or unintentionally hit unusually hard by an API client.
We are implementing rate limits with the following characteristics:
A token bucket algorithm is used. You can read more about token bucket algorithms here.
API rate limits are enabled per backend deployment, as well as per app user in that deployment for syncing data or making API requests from the JourneyApps Container.
There is a predetermined maximum sustained rate of requests per second that the API can accept.
There is a provision for burst capacity above the sustained rate. The burst capacity is the total number of requests allowed once the sustained rate has been exceeded. The burst rate is replenished when the number of requests made is less than the sustained rate.
When a request exceeds the request rate limit, the API will return a 429 HTTP response.
What do you need to do?
If the failure of any single request in an API broker or CloudCode task may break data integrity, you will need to update the broker to handle the 429 error response. We recommend that you see whether your API broker or CloudCode tasks could be impacted.
To handle the 429 response, you can implement the following logic where response errors are handled:
“If the response is 429, wait for at 1 second before retrying.”
Here is an example of the JSON response when an endpoint is rate-limited:
"title": "Too Many Requests.",
"detail": "Request rate limit exceeded for this account. Try again later.",
"retry_after": 60 // in seconds, a friendly suggestion
How do I check whether I am hitting the API near the rate limit?
There is no API endpoint that provides this information, so you will have to review your logs to track your usage. Our request limits are based on a one-second rolling window, so a pause of 1 second in the event of a 429 response should suffice in most cases.
As of January 2020, we have started returning a warning to API requests that exceed the rate limit.
When are we enabling rate limits?
Where can I see what the specific rate limits are?
You can see the API rate limits applied to a deployment on the Manage API page on the backend Data Browser.
Please take note:
Please contact JourneyApps Support for questions, raising limits, or extensions.