Do Your Installed Apps Share One Rate-Limit Bucket?
Installed apps never share one rate-limit bucket: Shopify's native scoping gives each app its own budget per store, so app count does not cause throttling. The REST bucket holds 40 requests per app per store and drains at 2 per second, or 400 and 20 on Plus (verified Sep 2026). A 429 names one app, not your app list. Fix the one integration that's overflowing and leave the app list alone.
Your profile — see how the verdict shifts
- Confidence
- High — Read Shopify's REST Admin API rate-limit page on 2026-09-05. The scoping is in the unit itself: bucket size is 40 requests per app per store with a leak rate of 2 per second, and both figures are increased by a factor of 10 for Shopify Plus stores, giving 400 requests and 20 per second. Per app, per store is the whole answer, and it means a store with 30 apps has 30 buckets rather than 30 tenants in one. GraphQL is scoped the same way, priced as calculated query cost per second at 100 points on standard plans, 200 on Advanced, 1,000 on Plus and 2,000 on Shopify for enterprise. One caveat on the source: the REST page also states that the REST Admin API is a legacy API as of October 1, 2024 and that all apps and integrations should be built with the GraphQL Admin API, so cite the REST numbers for what they are. On the market side we read the Store Management and Operations category in full, 24 listings covering workflow automation, bulk editing, backup and analytics, and none surfaces per-app Admin API consumption or manages a rate limit for a merchant. Shopify's own app documentation matches: an app's activity and permissions are reviewable from that app's page, and no consolidated cross-app view is described anywhere. So the architecture answers the question and the only build worth doing is logging inside the integrations you already own.
- Reference scenario
- $20M–$500M GMV · Shopify Plus · 25–40 installed apps plus two custom integrations · intermittent 429 and THROTTLED errors during launches · ecommerce lead weighing an app cull
- As of
- September 2026
Decision at a Glance
| Your profile | Verdict | Why |
|---|---|---|
| Many apps installed, no throttling errors reported | WAIT | Nothing to fix and nothing to fear. Thirty installed apps means thirty separate buckets of 400 requests each on Plus, not thirty tenants sharing one (verified Sep 2026). |
| 429 errors traced to a third-party app you don't control | WAIT | The overflowing bucket belongs to that app's developer, and so does the code. Send them the timestamps, ask what their call pattern is, and treat the answer as renewal information. |
| 429 or THROTTLED errors from an integration you own | BUILD | Your own bucket is the one overflowing, which makes this a code problem with a known owner. Log the rate-limit header on every response first, because you cannot pace what you cannot see. |
| Planning an app cull to relieve API pressure | WAIT | The cull buys nothing at this layer, because removing an app removes its bucket rather than freeing anyone else's. Prune for script weight, cost or admin clutter instead, which are real reasons. |
What Per-App Rate-Limit Bucket Scope Actually Drives
| Outcome | Impact | How it works |
|---|---|---|
| Operational efficiency | High | Knowing the bucket is per app redirects a multi-week app audit into a single integration's call pattern, which is where the throttling actually originates. |
| Revenue — indirect | Medium | Throttled order and inventory syncs publish late during launches, so the storefront sells against stale numbers on the highest-volume days. |
| Data & insight | Medium | A chart of bucket fill per integration turns launch-day throttling from an anecdote into evidence a vendor or a developer can be held to. |
| Customer experience | Low | Shoppers meet this only indirectly, through delayed stock updates when one integration's backlog clears slowly after a peak. |
Spend ceiling: Size the spend to a logging change, not an audit. The correction itself is free, per-integration logging runs $4,000–$12,000 at most (Deploi estimate, illustrative), and an app cull justified on API relief spends more than both and moves nothing.
What buying enables (top apps)
- + Nothing in this decision: no App Store listing we checked reports per-app Admin API consumption or manages a rate limit for a merchant (verified Sep 2026)
- + The nearest genuine benefit of pruning apps is elsewhere: storefront script weight, subscription cost and admin clutter are all real, and none of them is API contention
- + Shopify's own per-app activity and permissions view, which audits reach rather than call volume, one app at a time
What building additionally unlocks
- + Attribution: which integration filled its bucket, at what hour, on which endpoint
- + Alerting on bucket fill rather than on the 429 that arrives after the damage
- + A pacing strategy tuned to your own budget, since no other app's behavior affects it
- + Evidence to hand a vendor when their app is the one overflowing, which is the only leverage a merchant has there
Find Your Verdict in 3 Questions
Are you actually seeing 429 or THROTTLED errors, rather than assuming app count is a risk?
Yes: Go to question 2.
No: Your verdict: WAIT — every app has its own bucket of 40 requests, or 400 on Plus, so app count creates no contention to prevent.
Do the errors come from an integration your team wrote?
Yes: Your verdict: BUILD — log the rate-limit header per integration and pace inside your own bucket ($4,000–$12,000, Deploi estimate, illustrative).
No: Go to question 3.
Can the app's vendor tell you what call pattern their app runs?
Yes: Your verdict: WAIT — the fix belongs to that vendor's code; hold them to it and re-check after their next release.
No: Your verdict: WAIT — no merchant-side tooling exposes another app's bucket, so treat the non-answer as renewal information rather than an engineering project.
The TCC Scorecard — 12 Dimensions
TCC — Total Cost of Capability: what it actually costs to have this capability over three years, whichever way you get it. Each dimension is scored 0–5 for both paths. How we score →
| Dimension | Buy | Build | Why |
|---|---|---|---|
| Cost | |||
| Acquisition & implementation | No product exists to buy for this, and per-app call logging inside your own integration is days of work rather than a project (Deploi estimate, illustrative). | ||
| Recurring fees | Nothing recurring on either side, since the scoping is platform behavior; the only ongoing cost is whatever log storage your own telemetry already uses. | ||
| Maintenance & upgrades | Header names and cost-point accounting move with API versions, so logging code needs the same annual version review your integrations already get. | ||
| Switching & exit | There is nothing to switch away from: the bucket scoping is Shopify's architecture, and your logging is a few lines inside code you already own. | ||
| Risk | |||
| Vendor risk | The real vendor risk sits inside third-party apps whose call patterns you cannot see or change, which no purchase and no build on your side fixes. | ||
| Security & compliance surface | Logging your own request rate adds no new data holder and no new scope, since the numbers come from response headers your integration already receives. | ||
| Platform-deprecation exposure | The REST figures come from a page that also declares REST a legacy API as of October 1, 2024, so cite them for scoping and build new work against GraphQL. | ||
| Value | |||
| Fit to requirement | No app answers the question because the limits apply to apps rather than being managed for merchants; per-app logging answers it exactly, for the apps you wrote. | ||
| Time to market | Knowing the scoping is free and instant, and adding a logged rate-limit header to your own client ships in a single sprint. | ||
| Performance & scale | Per-app scoping means your store's headroom grows with each integration you add rather than being divided, so scale pressure is always inside one app. | ||
| Data ownership & AI-readiness | A logged history of bucket fill per integration turns intermittent launch-day throttling into a chart, which is the only evidence anyone can act on later. | ||
| Focus & opportunity cost | The cheapest win here is a correction rather than a project, because an app cull planned to relieve API pressure spends weeks and changes nothing. | ||
The App Landscape
| App | Status | Pricing | Best for |
|---|---|---|---|
| Shopify Admin API leaky bucket (per app, per store) | Native — First-party platform behavior, not a product. REST bucket size is 40 requests per app per store with a leak rate of 2 per second, increased by a factor of 10 for Shopify Plus stores to 400 requests and 20 per second (verified Sep 2026). GraphQL is scoped the same way and priced as calculated query cost, at 100 points per second on standard plans, 200 on Advanced, 1,000 on Plus and 2,000 on Shopify for enterprise. The REST page also declares REST a legacy API as of October 1, 2024. | Included with every plan; bucket size is set by plan tier, not by app count | Settling the question: every installed app draws on its own budget |
| Shopify admin app activity and permissions | Native — First-party Shopify. After installing an app you can review its activity and permissions at any time from that app's own page, and Shopify's documentation describes no consolidated cross-app view (verified Sep 2026). Read it for what it is: per-app permissions and activity, not a meter of Admin API calls. Nothing in the admin shows another app's bucket fill. | Included with every plan | Auditing what a single app can reach, one app at a time |
| API monitoring and observability apps (category) | Category — We read the Store Management and Operations category in full on 2026-09-05: 24 listings covering workflow automation, bulk editing, backup and analytics, and none surfaces per-app Admin API consumption. The absence has a cause worth stating plainly. Rate limits apply to apps rather than being managed for merchants, so there is no product to sell a merchant here. | Not applicable; no listing in this category reports per-app API consumption | Nothing in this decision, which is the finding rather than a gap in our search |
| Per-app call logging in your own integrations (custom) | Build lane — The only lane that adds visibility, and it only covers code you wrote. Record the rate-limit header on every Admin API response, tag it with the integration name, and alert when bucket fill crosses a threshold rather than when the 429 arrives. Third-party apps stay invisible no matter what you build. | $4,000–$12,000 one-time (Deploi estimate, illustrative), then negligible upkeep | Attributing throttling to a specific integration you own, with evidence instead of inference |
The Build Path
- Log the bucket, not the error: Record the rate-limit header from every Admin API response alongside the integration name and endpoint, then chart fill over time. Waiting for a 429 tells you the bucket already overflowed; watching fill tells you which job pushes it there and at what hour.
- Attribute by elimination for apps you don't own: Nothing in the admin exposes another app's bucket. Correlate the timing of your own errors with app activity you can see, then take the timestamps to the vendor. A vendor who cannot answer what their call pattern is has told you something useful for the renewal.
- Pace inside your own bucket instead of cutting apps: Since the budget is yours alone, the fixes are all local: batch related reads into one query, move large reads to bulk operations, and respond to changes through webhooks rather than polling. None of this depends on how many other apps are installed.
- Effort band
- $4,000–$12,000 to add per-integration rate-limit logging, attribution and alerting — Deploi estimate (illustrative); well under the $10–25K contact-form band, and often a single sprint
- Typical timeline
- 1–2 weeks, with the first chart of bucket fill available in days (Deploi estimate, illustrative)
- Maintenance, honestly
- ~15% of build cost per year (Deploi estimate): roughly $600–$1,800/yr (Deploi estimate, illustrative), essentially an annual check that header names and cost accounting still match the API version you target.
- What you own — and what you take on
- You own: the call log, the attribution and the alert thresholds for every integration you wrote. You take on: the permanent blind spot around third-party apps, whose buckets no merchant-side instrumentation can see.
3-Year Total Cost of Capability
| Buy (app path) | Build (custom path) | |
|---|---|---|
| Year 0 (setup) | $6,000–$20,000 (app audit and removals that change nothing here) | $4,000–$12,000 |
| Years 1–3 (recurring) | $3,000–$9,000 (repeat audits and re-installs) | $1,800–$5,400 (upkeep) |
| 3-year total | ≈$9,000–$29,000, with the throttling unchanged | ≈$5,800–$17,400, with the cause identified |
- † All figures illustrative samples for the reference scenario — not quotes, not verified pricing.
- † Buy column: an app cull undertaken to relieve API pressure, priced as the audit, migration and reconfiguration work it actually takes. No product exists to buy in this lane.
- † Build column: per-integration rate-limit logging, attribution and alerting across two custom integrations; three-year horizon.
What the Sticker Price Hides
On the buy path
- — An app cull sold internally as API relief spends weeks and changes nothing, because each removed app took its own bucket with it
- — Uninstalling apps has real consequences elsewhere, including lost configuration, broken theme blocks and re-onboarding cost, all paid for a benefit that never arrives
- — Blaming app count hides the actual offender, so the same throttling returns on the next launch with fewer suspects left
- — No listing in the categories we checked reports per-app API consumption, so a monitoring purchase here buys dashboards of something else (verified Sep 2026)
On the build path
- — Logging only the 429 tells you the bucket already overflowed; log fill on every response instead
- — Header names and cost accounting differ between REST and GraphQL, so one logging path will not cover both lanes
- — Third-party apps stay invisible permanently, which limits what any amount of your own instrumentation can conclude
- — ~$600–$1,800/yr upkeep, mostly an annual version check (Deploi estimate, illustrative)
What Merchants Say
Ecommerce leads describe arriving at the same wrong conclusion during a launch: throttling errors appear, the app list looks long, and an app audit gets scheduled instead of a look at the one integration polling orders every second.
Developers report the opposite frustration, that they can prove their own integration is inside its budget and still cannot see what any other installed app is doing to the store.
If You Change Your Mind Later
If you bought and outgrow it
There is nothing to exit, because nothing was bought. What an app cull leaves behind is the cost of undoing it: reinstalling apps, restoring configuration, and re-onboarding staff on tools that were removed for a reason that did not apply. Before committing to a cull, write down the benefit you expect and check it against the per-app scoping.
If you built and want out
Nothing strands. Rate-limit logging lives inside your own integrations, moves with them to any future stack, and keeps working after a replatform. The artifact worth keeping is the chart of bucket fill per integration, since it is the evidence that settles the same argument the next time a launch produces throttling errors.
When This Answer Changes
We're watching for:
- ▸ Shopify shipping any merchant-facing view of API consumption per installed app, which would end the elimination method entirely
- ▸ A change to the per-app, per-store scoping itself, which is the one platform change that would make app count matter
- ▸ Your own migration off REST, since the legacy notice dated October 1, 2024 means the bucket numbers you monitor should be the GraphQL cost points instead
Verdict change log:
No changes since first publication (September 2026).
Common Questions
Do Shopify apps share the same API rate limit?
No. Each app gets its own leaky bucket per store, sized at 40 requests draining at 2 per second on standard plans (verified Sep 2026). Shopify Plus raises that to 400 requests draining at 20 per second. Two apps never draw down the same pool, so installing another app removes no headroom from the ones already there.
Will uninstalling apps fix Shopify 429 errors?
No. Removing an app removes its own bucket of 40 or 400 requests and frees nothing for anyone else, because the limit is scoped per app per store (verified Sep 2026). A 429 identifies the single app that exceeded its own budget. Prune apps for script weight, subscription cost or admin clutter, which are real reasons.
How do you find which app is causing Shopify API throttling?
Start with the integrations you own by logging the rate-limit header on every Admin API response, tagged by integration name. Shopify's admin lets you review an app's activity and permissions from that app's own page and describes no consolidated cross-app view (verified Sep 2026). For third-party apps, correlate error timestamps and take them to the vendor.
Your Next Steps
If you're going with WAIT(matches your selected profile)
- Write the scoping rule where your team can see it: one bucket per app per store, 40 requests standard and 400 on Plus
- Cancel any app cull whose stated benefit was API relief, and re-justify it on script weight or cost instead
- Collect timestamps for every throttling error before assigning a cause
- Ask each suspect vendor what call pattern their app runs and record the answer for renewal
If you're going with BUILD
- Log the rate-limit header on every Admin API response, tagged with the integration name and endpoint
- Alert on bucket fill crossing a threshold rather than on the 429 that follows it
- Batch related reads into single queries and move large reads to bulk operations
- Replace polling loops with webhooks wherever the event exists
- Chart fill per integration across a launch day, and keep the chart as the answer for next time
Official Docs & Sources
- REST Admin API rate limits — shopify.dev
- Admin API rate limits (GraphQL) — shopify.dev
- Installing and reviewing apps — Shopify Help Center
Official documentation linked for verification — our verdicts and estimates are our own.
Related Decisions
Build or Buy Observability for Checkout Functions on Shopify?
Shopify documents 12 function error types and stores each run in the Dev Dashboard, but no default alert tells you a checkout function has started failing.
Do Customer Accounts Follow Shoppers Across Plus Stores?
Each Plus store keeps its own customer records, so accounts don't follow shoppers between stores. Multipass rides legacy accounts Shopify deprecated.
Should You Build or Buy Cross-Store Staff Access on Plus?
Custom organization-level roles give one staff login reach across a Plus organization. No app grants staff access across stores; below Plus, every store is separate.
Customer Account API vs. a Custom Login System on Headless?
Shopify's Customer Account API authenticates buyers on headless. A custom login build costs six figures, and legacy accounts are deprecated since February 2026.
Build or Buy Performance Monitoring & App Audits on Shopify?
Measurement is free on Shopify; storefront speed comes from an audit-and-remediation program, not a speed app.
Ready to blame the right integration?
We add rate-limit logging to the code you own, chart bucket fill by integration, and hand you the timestamps for anything a vendor needs to answer for. Usually the cull gets cancelled.
Contact us todayVerdict scored for the reference scenario above. Estimates are not quotes; app pricing carries its verification date and gets re-verified quarterly. Full scoring anchors: see the TCC methodology.
Read how we score these decisions (the TCC Framework). No affiliate links, no paid placement — no app vendor pays to appear here.