Shopify API Leaky bucket algorithm for dev store

Retired Boards Appdev Partners Discussion

AI-generated summary

Issue: Frequent “429 Too Many Requests” when processing a small number of orders via the Shopify API on a dev store. Response headers show X-Shopify-Shop-Api-Call-Limit as “1/40” and no Retry-After header. The poster asks how the leaky bucket algorithm behaves in dev vs production stores.

Limits described by a responder:

  • Bucket size of 40 calls per minute and a drain rate of 2 calls per second.
  • For Shopify Plus stores, limits said to double to 80/min and 4/sec.

Possible cause and mitigation:

  • Asynchronous behavior (e.g., in Node.js) can burst multiple requests within the same second, exceeding the per‑second drain even if the minute bucket seems underused.
  • Suggested solution: implement a request queue that spaces calls based on the time of the last request to avoid 429s.

Open questions/Status:

  • No definitive clarification on whether dev vs prod stores have different rate limits.
  • No explanation given for the missing Retry-After header.
  • Discussion remains unresolved beyond general rate-limit guidance.
1

Hello,

We are getting “429 Too Many requests” after processing very few orders in the Dev Shopify store via the API.

Also, we see that the header **"**X-Shopify-Shop-Api-Call-Limit" is returned the value as “1/40” and the Retry-After header is also not returned in the response. Please respond to us with, how this leaky bucket algorithm will work exactly in Dev store vs Prod store.

kindly share your inputs. Thanks!

2

It has two limitations on the API:

of 40 calls per minute and 2 calls per second

(if the store is plus this limit doubles to 80 calls per minute and 4 calls per second)

I had a problem using node referring to asynchronism using the call stack that made the calls all be in the same second even putting a setinterval or creating delay because each new call went to another thread maybe you are having a problem exceeding 2 calls per minute the ideal is to create a queue and call based on the time of the last call so as not to make an error 429