Shopify API Rate Limits: Managing Multiple Stores
How the Shopify Admin API rate limit works across multiple stores: leaky bucket mechanics, GraphQL rate limit cost, bulk ops, and throttling fixes.
Key points — AI summary
- Shopify's REST API uses a leaky-bucket model per store per app — standard plans get 40 requests of capacity draining at 2/sec, Plus gets 400 capacity draining at 20/sec
- GraphQL uses cost-based limiting instead (100 points/sec standard, 200 Advanced, 1000 Plus), with a single query capped at 1,000 points and unused points refunded after each run
- Running the same sync across many stores multiplies pressure — 30 parallel workers across 30 stores can exhaust all buckets simultaneously even though each store stays within its own per-store limit
- Bulk operations bypass the per-query cost ceiling and, since API version 2026-01, allow up to five concurrent bulk mutations per store (up from one before 2026), but must complete within 10 days
- Fix multi-store throttling with a backoff-and-queue system: pause calls to an exhausted store, route workers to stores with capacity, batch per store rather than globally, cache aggressively, and prefer GraphQL for multi-field fetches since it often replaces several REST calls at similar cost
Summarized from this article by our writing pipeline; reviewed by the author.
On this page
- How the Shopify Admin API Rate Limit Works: The Leaky Bucket
- The Shopify GraphQL Rate Limit: A Cost-Based Leaky Bucket
- Bulk Operations: The Rate-Limit Escape Hatch
- Real Multi-Store Challenges and Solutions
- Choosing REST vs GraphQL for Multi-Store Ops
- Why This Matters When One Tool Talks to Every Store
- Sources
Running multiple Shopify stores from a single platform creates a unique challenge: you're not just hitting one store's API limits, you're accumulating rate-limit pressure across dozens or hundreds of stores simultaneously. Understanding how the Shopify Admin API rate limit actually works—the REST leaky bucket, the GraphQL cost model, and how both compound when you manage many stores—is essential to keeping orders flowing, inventory syncing, and operations smooth.
How the Shopify Admin API Rate Limit Works: The Leaky Bucket
Shopify's REST Admin API rate limit uses a leaky bucket algorithm to manage request capacity. Think of it like a container that fills with each API request and empties at a steady rate over time.
Here's the mechanics:
- Bucket capacity: Standard plans get a bucket of 40 requests per app per store. Shopify Plus accounts get 400 (a 10x multiplier).
- Leak rate: Requests drain from the bucket at a fixed rate—2 requests per second for standard plans, or 20 requests per second for Plus.
- Burst allowance: If you've been making requests slowly and your bucket is nearly empty, you can make a burst of up to 40 requests at once without hitting the limit, because there's room in the bucket. Once the bucket fills, you get a
429 Too Many Requestserror.
Shopify returns the header X-Shopify-Shop-Api-Call-Limit: 32/40 in responses, showing your current usage versus remaining capacity.
The multiple-store problem: When you manage 30 stores, you get 30 separate buckets—one per store per app. If your background workers are syncing inventory, pulling orders, or updating products across all 30 stores in parallel, you can deplete all 30 buckets simultaneously and hit throttling across the entire operation, even if you're within the per-store limit.
The Shopify GraphQL Rate Limit: A Cost-Based Leaky Bucket
Shopify's GraphQL Admin API rate limit uses a different unit: query cost. Instead of counting individual requests, every query is assigned a cost based on its complexity and the amount of data it requests. Under the hood it's still a leaky bucket—the GraphQL leaky bucket just holds points instead of requests, refilling at a steady rate per second.
Cost model fundamentals:
- Every field in the GraphQL schema has an integer cost value.
- Scalar fields (like strings or numbers) cost 0; object fields cost 1; connection fields (lists) cost more based on how many records you request.
- Your app receives an allocation of points per second, draining from a per-store points bucket the same way REST calls drain the request bucket.
Rate limits by plan:
- Standard: 100 points per second
- Advanced Shopify: 200 points per second
- Shopify Plus: 1000 points per second
A single query cannot exceed 1,000 points, regardless of plan. Once a query runs, Shopify recalculates its actual cost and refunds unused points back to your bucket.
Why this matters for multi-store apps: A query that costs 50 points on one store still costs 50 points on another. If you're running the same reports, syncs, or bulk operations across 20 stores, you burn through your per-second allocation quickly. With limited points, you must either throttle requests, batch them across time, or use bulk operations to bypass single-query limits entirely.
Bulk Operations: The Rate-Limit Escape Hatch
Bulk operations are designed to handle large volumes of data without hitting the single-query cost ceiling. They don't count against your per-second rate limit in the same way—instead, they queue asynchronously and process in the background.
Starting in API version 2026-01, you can now run up to five bulk mutation operations concurrently per store. Before 2026, you could only run one at a time. This is significant for multi-store operators: you can queue bulk updates, syncs, or imports across multiple stores without serializing them.
Bulk operations must complete within 10 days. If you're syncing products, customers, or orders across dozens of stores, bulk operations let you fire off requests without worrying about immediate rate-limit pushback.
Real Multi-Store Challenges and Solutions
When you run a platform managing 10, 50, or even 150 stores, API rate limits become an operational bottleneck. Here's why:
The cumulative load problem: 30 background workers making Shopify API calls in parallel across 30 stores can deplete all available quota almost instantly. One worker per store, each pulling orders or syncing inventory, totals 30 requests spread across 30 separate buckets. That's fine in isolation. But coordinating across stores—pulling orders from all 30, then updating inventory on all 30, then pushing to your operational system—requires careful orchestration.
The solution: Implement a backoff and queue system. When a store's API quota is exhausted:
- Stop making calls to that store for a few seconds.
- Route workers to other stores whose buckets still have capacity.
- Resume that store's queue once the leaky bucket drains enough to allow new requests.
Also consider:
- Batch by store, not globally: Process one store's full sync (orders, inventory, customers) before moving to the next, rather than trying to sync all stores in parallel.
- Use caching aggressively: If you're fetching customer or product data multiple times per sync cycle, cache it locally for minutes or hours instead of hitting the API repeatedly.
- Optimize queries: In GraphQL, only request the fields you actually need. Every field adds cost. In REST, use resource filtering and pagination limits to reduce response payloads.
Choosing REST vs GraphQL for Multi-Store Ops
REST API is simpler to understand and implement. The bucket and leak rate are predictable. It's good for straightforward, lightweight operations like pulling orders or updating order status.
GraphQL is more flexible and lets you fetch exactly what you need in a single request. Complex queries can reduce the number of round-trips you need. But query cost requires more careful planning and testing to avoid surprises.
For multi-store platforms, GraphQL often wins because you can fetch related data (orders, line items, customer info) in one query instead of making three REST calls. One efficient GraphQL query may cost the same as three REST requests but completes faster and uses your quota more predictably.
Why This Matters When One Tool Talks to Every Store
A tool that manages your entire multi-store operation from a single dashboard—orders, revenue, shipping, and finance across all your stores—has to be rate-limit-aware by design. In our own build that means APIs that:
- Queue requests across stores to avoid exhausting any single store's bucket.
- Use GraphQL and bulk operations to minimize API calls per sync.
- Batch operations intelligently so you see real-time data without throttling.
If you're managing 10 stores manually in separate Shopify admin tabs, you're already multiplying your operational complexity. A unified multi-store platform handles rate-limit orchestration for you, so you can focus on growing your stores instead of debugging API errors.