Rate limiting on the String API

Hey there!

Last Thursday the 12th of December in the morning WebTranslateIt was hit with severe performance issues. The website and the API became unavailable at time.

Every 10 minutes, we received massive waves of requests (more than 400 requests per seconds on the API), which made the web server very slow.

Upon investigation, we found out that the performance issues were due to some users using automated tools performing requests on the String API. We always intended this API to be rate limited (in fact, our documentation has always stated that we limit requests up to 25 requests per seconds), but we noticed that some users were using the API way over 100 requests per seconds, so our rate-limiting was clearly not working.

We are now properly limiting this API up to 25 requests per seconds with bursts up to 30 requests per seconds. We think this is a very reasonable limit given the fact that this API serves up to 250 segments and all their translations, and requesting over 30 requests per seconds to one web service really is doing a lot of requests.

If you get a HTTP error code 429 Too Many requests it means that you are being hit by our rate-limiter. The only way to avoid this limit is by reducing the amount of requests you are doing to that endpoint. You can do that by implementing caching or by introducing a few milliseconds pause on the device performing the request. We limit requests by IP and by organization. If you cannot use caching nor can you pause the server doing these requests, are you using the correct API for this job? The File API for instance, lets you download all the segments of a file in one request.

Properly rate-limiting this API is essential. Having no rate-limit to this API results in a unreliable API and service in general.

If you need any help or have any issues with our API, don’t hesitate to contact us.