Starting January 22, 2025, Shoptet will implement a new rate-limiting mechanism to improve API integration stability and efficiency. This system ensures secure operation and aligns integrations with best practices.
Timeline
We are only launching the informative part now, which means that rate-liming is only descriptively reporting the error behavior of integrations using the channels mentioned above (e-mails and headers).
After about 3-4 months from the start of public soft-validation and testing, we will start physically rejecting inefficient requests to avoid overload, to which we will respond with HTTP status code `429 – Too many requests.’
During this time, the integration on a specific project will be inoperative.
What do the changes concern?
We want to prevent API overloading, ensure smooth, secure performance, and encourage you to use best practices.
We recommend you investigate the specific integrations, evaluate the data we eventually sent you, and, ideally, make the necessary optimizations according to the documentation, standards, and best practices. We are ready to help you as much as we can.
How does rate-limiting work in Shoptet?
In addition to the current rate-limiting, we have also prepared more detailed rules for checking the efficiency of calling your integrations using a leaky bucket.
How do we inform you about reaching the limits?
Headers
In every response, there is an X-RateLimit-Bucket-Filling header, which contains the current value of bucket filling.
If the bucket is fulfilled, we also return Retry-After header with a date-time value indicating when you can start requesting our API again.
Shoptet calculates the complexity of a query after execution. The actual complexity is based on the query results.
Each app has access to a bucket. It can hold, say, 200 “drops”.
Each API request tosses some number of drops into the bucket.
Each second, 10 drops are removed from the bucket (if there are any), restoring capacity for other drops.
If the bucket gets full and there is no space to add new “drops” from incoming requests, you will get an error (429) and have to wait for bucket capacity.
Why are we describing bucket size and leak rate in “drops”?
Every request has different demands on our resources, i.e., a product list with many products and query filters included vs. an e-shop info endpoint.
For this reason, we have to calculate the complexity, which does not exist in any unit – that is why “drops”.
Calls from one add-on don’t affect the rate limits of another add-on made by you, even on the same project. Similarly, calls to one project don’t affect the rate limits of another project, even from the same add-on.
Emails
We send emails twice daily (at 8 am and 2 pm).
The emails retrospectively send aggregated data as a summary in a certain time box, which helps you in reverse investigation.
Emails contains the indicators, which mean:
🟠 Orange – your bucket was almost full. Please make a basic investigation of the root causes here.
🔴 Red – your bucket is overloaded. Your integration was suspended in certain time windows.
Who receives the emails?
If you are the creator of the add-ons, the emails will be sent to the contact email listed with the add-ons.
If it is a Premium integration, the emails will go to the primary project contact, with whom you, as a partner, will need to set up an internal process on your part to forward this information following the GTC.
All premium e-shop owners were also informed with explanations and instructions on how to proceed, together with you, the integrators.
Please note: It is not possible to set a non-subscription or change the destination email address, which must match the settings of the project (Premium) or add-on.
What to do if you have questions?
We understand that this information may raise questions or concerns.
Please do not hesitate to contact us at api@shoptet.cz, or your partner manager.
