Determine if HTTP 429 is because leaky bucket is full or other breach?

Shopify Partner
59 2 8

How can I determine if HTTP 429 is because leaky bucket is full or other because of another breach?

 

If it's because of a full bucket, I would like my program to wait and retry.

If it's another breach, it might take several hours before a retry succeeds, so I would like to throw an error.

 

Any ideas?

0 Likes
Highlighted
Shopify Staff
Shopify Staff
426 57 65

Hey @ClementBR ,

 

Assuming you are using the REST Admin API, every API request to the Shopify will contain in the response headers the header of "X-Shopify-Shop-Api-Call-Limit". This header lists how many requests you’ve made for a particular store. For example if you only send one request it will have the value of "1/40", and if you make 32 requests it will have the value "32/40". You can track this header, and know that once you see this header reach the call limit (e.g. 40/40) you will retrieve 429 "Too Many Request" Error from Shopify. Also upon receiving the 429 "Too Many Request" Error from Shopify for reaching the API call limit, there should also be a response header called "Retry-After" which will tell you how many seconds to wait before making another request again.

 

If you are using the GraphQL Admin API this is even easier, since the API rate status is returned in the body of every response. So you should always know how much of the API bucket you have used, and how much of the bucket is still left remaining after every request

 

https://shopify.dev/concepts/about-apis/rate-limits#graphql-admin-api-rate-limits

Hassain | Developer Support Specialist @ Shopify
 - Was my reply helpful? Click Like to let me know! 
 - Was your question answered? Click Accept as Solution 

0 Likes
Highlighted
Shopify Partner
59 2 8

Thanks @hassain , I am well ahead of this header but I think I wasn't clear enough in my question.

 

It looks like Shopify does NOT include the X-Shopify-Shop-Api-Call-Limit header in the 429 response.

 

So, when we do hit a 429, how do we know if it was caused because the leaky bucket is full (in which case we want to retry) or if it was caused by another limit, such as the daily variant creation limit (in which case we DON'T want to retry)?

0 Likes
Highlighted
Shopify Partner
43 4 8

The message attached with the daily creation limit 429 is slightly different.
It contains something like Product Variant daily creation limit reached, where as the leaky bucket limit 429 does not contain that.

 

To make things more clear the message has been passed to Shopify lets hope we get a better solution soon.

https://community.shopify.com/c/Shopify-APIs-SDKs/50k-variant-limit-check/m-p/672775

Need some help or work done? Hire me!
0 Likes
Highlighted
Shopify Partner
59 2 8

Relying on undocumented error text message would be very brittle so we'd rather avoid it.

In addition, other limits such as the test store 5 orders per minute show a message similar to the full leaky bucket message, even though it's clearly not the cause.

0 Likes
Highlighted
Shopify Partner
43 4 8

True but got no other option at the time.

Need some help or work done? Hire me!
0 Likes
Highlighted
Shopify Staff
Shopify Staff
426 57 65

Hey @ClementBR ,

 

Thanks for the additional context you provided. As per my original comment:

 

upon receiving the 429 "Too Many Request" Error from Shopify for reaching the API call limit, there should also be a response header called "Retry-After" which will tell you how many seconds to wait before making another request again.

I am fairly confident this "Retry-After" header only occurs if the leaky bucket is full and it is not present for 429 Errors that occur due to non-rate limiting reason. So from my perspective, you can use the existence of this header to know that you received the 429 Error because you hit the API Limit.

 

Hassain | Developer Support Specialist @ Shopify
 - Was my reply helpful? Click Like to let me know! 
 - Was your question answered? Click Accept as Solution 

0 Likes
Highlighted
Shopify Partner
59 2 8

I am fairly confident this "Retry-After" header only occurs if the leaky bucket is full 

Interesting, is this something we can rely on?

 

Other limits are also time based in nature, for example the limit "1,000 new variants per day", it would also also make sense to include a Retry-After value to retry at the end of the day.

0 Likes