It is usually fixable. Most peak-sale rate limit problems come from how the app calls the API, not from Shopify’s limits themselves. Three fixes cover most cases: move large jobs to bulk operations, migrate from REST to GraphQL with right-sized queries, and queue writes per shop with throttling. It is a design problem when the app polls, calls the API once per item or calls it on every page view.
Check first which limit you are hitting. REST and GraphQL use different models, and each app and shop pair has its own quota. Our custom Shopify app development team audits apps for exactly this.
The two limit models
Knowing which one you are hitting changes the fix.
| Model | How it works | What to watch |
| GraphQL Admin API | Leaky bucket measured in query cost points. A query cannot exceed 1,000 points. | Restore rate is 100 points a second on Standard, 200 on Advanced, 1,000 on Plus and 2,000 on enterprise. |
| REST Admin API (legacy) | Request-count limits. It is sunsetting for public apps. | Move calls to GraphQL so you can see and control cost. |
- A THROTTLED response arrives as a 200 with a GraphQL error, not as a 429.
- Requested cost is checked before the query runs, and the difference is refunded afterward.
- Array inputs are capped at 250 items on every Shopify API.
- Bulk operations have no maximum query cost.
The three fixes
Apply them in this order.
Use for: large reads and writes, such as full exports or catalog updates.
Notes: bulk mutations are limited to one connection field and 100 MB of input, and up to five can run at once per shop on API version 2026-01 and later.
Do: request only the fields you need, avoid first: 250 by default and avoid deeply nested connections.
Result: lower query cost and visible cost on every response.
Do: read the cost data on every response, slow down when capacity is low and retry throttled calls using the wait time the data implies.
Use webhooks, not polling
Polling is the most common design problem.
- Subscribe to orders and inventory webhooks instead of fetching on a timer.
- Webhook deliveries do not use your API bucket.
- Verify the signature and enqueue the event before heavy work.
- Add a nightly reconcile job for anything missed.
When it is a design problem
These patterns do not scale, whatever the limits.
Rule of thumb: if a store’s traffic doubles and your API calls double too, the design will not survive growth.
A code-audit approach
A focused audit gives you the real estimate.
- Log throttle status and requested versus actual cost on every call.
- Count API calls per feature and per page view.
- List every polling loop and every per-item call.
- Check how failures retry and whether anything queues.
- Review the API version and any REST usage.
Event-driven sync in practice
A webhook-based order sync with structured data mapping, error handling and failure logging that replaced manual CSV exports and scheduled batch jobs. The same pattern connects new stores through configuration. The case study reports no throughput figures.
Read more: our Fanbase Shopify app case study
Share your app’s API logs and peak-sale pattern, and our custom Shopify app development team will tell you whether it needs tuning or a redesign, with an effort range.
Frequently Asked Questions
Often yes. Polling loops, one call per item, calls triggered by page views and no queue are design problems. Occasional throttling during a sale on an otherwise efficient app is usually fixable with queues and bulk operations.
Limits use a leaky bucket measured in query cost points. The restore rate is 100 points a second on Standard, 200 on Advanced, 1,000 on Plus and 2,000 on enterprise, and no single query can exceed 1,000 points.
No. Webhook deliveries do not draw from your API bucket, which is why webhooks beat polling for orders and inventory changes.
Yes. The REST Admin API is legacy and sunsetting for public apps, and GraphQL gives you cost visibility and bulk operations. See how this fits a custom app for warehouse picking.
A reasonable planning range is days for query and retry fixes and weeks when the app polls or runs synchronous calls and needs a new queue design. An audit sets the real estimate.
