API protection measures
The Loco API still (at time of this notice) has no quota-based rate limits. This means the number of requests you can make (per hour/day etc..) is not monitored or enforced.
Introducing API rate limiting is inevitable, but this will be rolled out slowly. In the mean time, we're taking steps to mitigate the problems caused by traffic spikes.
Strict API parameters
As of this date the API will start rejecting unsupported query string parameters.
Loco implements internal caching measures to alleviate the load on our databases when unchanged data is repeatedly requested.
Our cache observes unique URLs and is implemented in a layer that has no knowledge of the API itself. As such, sending "cache busting" queries like /api/export/all.json?nocache=1651569699370 renders our cache worthless and adds significant load to our databases.
You should never need to get around our cache. If it's working properly then you won't notice it. Please get in touch with us if you're seeing stale data. There will be a good reason for it, and if that reason is a bug then we'll fix it and be grateful for your help in doing so.
If you're trying to get around your own cache, then please examine the root cause at your end. Browsers and other caches should observe the response headers sent from our API, so please let us know if you see a problem with our responses.
Response throttling
If you are experiencing slower responses than normal, please review your API usage against our fair usage policy
Aggressive polling is a particular problem for our servers. In the absence of web hooks (which we plan to add) many users request the same data with very high frequency to detect when data has changed. Even with our caching measures, this can degrade the service and is considered abusive when it reaches an unreasonably high level.
Clients that pose a risk to our service will be slowed down. This effectively reduces the number of request that can be made. Attempting to speed this up by making simultaneous requests may be effective to a point, but parallel requests will be queued and will result in 429 responses if the queue becomes too long.
Blocked IP addresses
This is extremely rare, but clients that are actively damaging our service will be temporarily blocked while we investigate
We only block IP addresses if a client is sending an extremely high level of traffic that is evidently degrading our service. For example, downloading a 10MB file multiple times per second will be treated as a denial of service attack. Please consider how your traffic looks from our side.
We may contact you before taking this measure, but if we're receiving complaints from other customers then we're more likely to block first and ask questions later.
Rate limiting in future
We understand that developers expect REST APIs to be "fire and forget" and we're working hard to meet these expectations. However, rate limiting is common for APIs like ours and we made a mistake by not implementing it from the beginning.
Once we roll out a formalized rate limiting policy we'll correspond with all customers to ensure they're prepared. In the mean time we recommend developers anticipate 429 response codes, even if they're not currently receiving any.