Rate Limiting
About Rate limitation
Rate limitation is used to control incoming network traffic, mainly to prevent unnecessary overloads and malicious attacks.
Limitations on Shardimage
API endpoints and frontend features are protected by rate limitation. As an image manipulating and serving service, on Shardimage this affects the users in uploading and managing images and their services, image serving is not limited.
Rate limited API services
List of our limited API services with limitation numbers and intervals.
Billing
Listing user’s billing data:
| Action |
Interval [sec] |
Limit [request/interval] |
| all |
60 |
180 |
Cloud managing
| Action |
Interval [sec] |
Limit [request/interval] |
| create |
60 |
1 |
| update |
120 |
40 |
| all |
60 |
180 |
Firewall
| Action |
Interval [sec] |
Limit [request/interval] |
| create |
120 |
10 |
| update |
120 |
10 |
| all |
60 |
120 |
Image management through API
Listing image tags:
| Action |
Interval [sec] |
Limit [request/interval] |
| index |
60 |
300 |
Image management:
| Action |
Interval [sec] |
Limit [request/interval] |
| list by public id |
60 |
200 |
| delete by tag |
60 |
200 |
| delete |
60 |
rising dynamically |
| all |
60 |
rising dynamically |
Image upload
| Action |
Interval [sec] |
Limit [request/interval] |
| all |
60 |
600000 |
| all by cloud |
60 |
rising dynamically |
Job management:
| Action |
Interval [sec] |
Limit [request/interval] |
| all |
60 |
300 |
Secure module - managing access tokens
| Action |
Interval [sec] |
Limit [request/interval] |
| all |
60 |
60000 |
Super Backup
| Action |
Interval [sec] |
Limit [request/interval] |
| create |
60 |
2 |
| update |
60 |
10 |
| all |
60 |
180 |
Log
| Action |
Interval [sec] |
Limit [request/interval] |
| all |
60 |
100 |
System module - ping function
| Action |
Interval [sec] |
Limit [request/interval] |
| all |
60 |
5000 |
Dynamically rising limits
In these special cases, there are limit levels, not a fixed one. The limitation starts at a low level and gets higher as the request count rise. The system will check the last 4 minutes of the user’s activity, and if it reaches the 80 percent of the limit, or even reach the rate limitation, it moves to a higher level. The checked interval is always the last 4 minutes, if there are no requests for a few minutes, the rate limit will remain the reached level. But if there are no requests at all for longer time, the rate limiting will start from the first level again.
Handling rate limitation
We provide rate limit informations in response headers:
X-Rate-Limit-Limit: the maximum number of allowed requests during an intervalX-Rate-Limit-Remaining: the remaining number of allowed requests within the current intervalX-Rate-Limit-Reset: the number of seconds to wait before having maximum number of allowed requests again
We have already implemented rate limit handling in our SDKs, check these link for further information: