Shopify API Rate Limits During Black Friday: How to Keep Your Sync From Falling Behind
Most integrations are tested on an ordinary Tuesday. Black Friday is not an ordinary Tuesday. Orders arrive many times faster, your own jobs fire more often, and every system you connect starts asking Shopify for data at the same moment.
That is when you meet the Shopify API rate limits for the first time, usually at the worst possible hour.
How the limits work, in plain terms
Shopify does not give you unlimited calls. The older REST API used a leaky bucket idea: you can make a burst of calls up to a cap, and the bucket drains at a steady rate. The GraphQL API works on cost. Each query has a point cost based on what it asks for, and you have a bucket of points that refills over time.
The exact numbers depend on your plan and they change, so read the current Shopify documentation instead of trusting a blog post, including this one. What matters is the behavior. When you go over, Shopify answers with a 429 status and tells you how long to wait. If you ignore that and keep hammering, you only make things worse.
Also note that Shopify has been moving developers toward GraphQL, so if your integration still depends on older REST calls, it is worth checking what is supported before a big sale.
What goes wrong on a busy day
I see the same few patterns when a sync falls behind:
- A single worker doing everything. One slow call blocks every order behind it.
- Retrying immediately. After a 429, the code tries again right away, fails again, and burns the budget.
- Polling instead of listening. A job that asks “any new orders?” every few seconds uses limit budget even when nothing has changed. Webhooks cost nothing against that budget.
- Big jobs competing with urgent ones. A catalog update or a full inventory refresh starts at noon and starves the code that needs to fulfill orders.
- No visibility. Nobody knows the queue is hours behind until a customer complains.
Design for it before the sale
Put every Shopify call behind a queue. Never call the API directly from a web request or a webhook handler. Workers pull jobs at a rate you control.
Cap concurrency. Decide how many calls per second your integration is allowed to use, leave headroom for other apps on the same store, and enforce it in one place.
Respect the wait instructions. When Shopify says wait, wait for that long, then retry. Add a bit of random jitter so many workers do not wake up in the same instant.
Prioritize. New orders and fulfillments come first. Product description edits and reports can wait. Two queues with different priorities solve this without much code.
Prefer webhooks and bulk reads. Listen for changes instead of polling. When you need a big export, use the bulk operation tools Shopify provides instead of paging through thousands of records.
Cache what rarely changes. Product data, locations, and shipping settings do not need to be fetched for every order.
Test it, with a realistic load
The cheapest fix is to find the bottleneck in October. Replay a day of real order volume against a development store, then multiply it. Watch where the queue grows. You are looking for the first thing that falls behind, because that is the thing that will fail first on the day.
Also decide in advance what you will do if you do fall behind. Who gets the alert? Can you pause the low priority jobs? Do you know how to replay a stuck queue safely? The answers should be on a short page that anyone on the team can find, not in one person’s head.
It is not too late
If you are reading this in early November, you still have time to do the basics: move calls behind a queue, add backoff, and set up an alert for queue depth. Those three changes prevent most of the pain.
I wrote about the related problem of orders getting lost between systems in Shopify Webhooks Missing Orders. The two problems tend to appear together, because a system that is rate limited also drops or delays the events behind it.
If you would like a second pair of eyes on your sync before the sale, email kevin@kevinhq.com with a short description of what is connected to your store. A one hour review before BFCM costs far less than a day of manual order entry.