Shopify API Rate Limits: Managing Multiple Stores
How to understand Shopify REST and GraphQL API rate limits when running multiple stores, including leaky bucket mechanics, cost models, and strategies to avoid throttling.
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 Shopify's API rate-limiting systems work—and how they compound when managing many stores—is essential to keeping orders flowing, inventory syncing, and operations smooth.
How Shopify REST API Rate Limits Work
Shopify's REST Admin API 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.
GraphQL Admin API: Cost-Based Rate Limiting
Shopify's GraphQL Admin API uses a different model: query cost. Instead of counting individual requests, every query is assigned a cost based on its complexity and the amount of data it requests.
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, split into a per-store bucket similar to REST.
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 for StoreFleet Users
StoreFleet manages your entire multi-store operation from a single dashboard—orders, revenue, shipping, and finance across all your stores. To do that reliably, we've built rate-limit-aware 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.
Want to see how StoreFleet handles rate limits and syncs across your stores? Try a free demo on your own Shopify account. Just reach out at [email protected] or schedule a demo on our homepage.