Shopify App Access Scopes: Read vs Write Explained
Shopify app access scopes decide what your app can read or change. Learn why Shopify pushes write-to-read downgrades and how to audit scopes safely.
Shopify app access scopes are the permissions your app requests when a merchant installs it, and each one is either read or write. Read scopes let your app view data such as products or orders; write scopes let it change that data. Shopify now pushes apps to downgrade from write to read wherever possible, because every unnecessary write scope is a security risk and an app-review problem.
If your app still asks for write_products just to display a catalogue, or write_orders just to show a dashboard, that is the issue this guide fixes. Below is what scopes actually control, why Shopify is pushing the downgrade, how to audit what you really need, and how to trim scopes without breaking existing installs.
What Shopify app access scopes actually control
Scopes are grouped by resource. Each resource usually has a read scope and a write scope, and write normally implies read.
| Scope | What it allows | Typical use |
|---|---|---|
read_products |
View products, variants, collections | Catalogues, bundles, SEO tools |
write_products |
Create, update, delete products | Bulk editors, inventory sync |
read_orders |
View orders and line items | Reporting, analytics |
write_orders |
Edit orders, fulfilments, refunds | Fulfilment automation |
read_customers |
View customer records | Segmentation, CRM sync |
write_customers |
Create or update customers | CRM sync, loyalty apps |
read_inventory |
View stock levels | Stock dashboards |
write_inventory |
Adjust stock levels | Warehouse and ERP sync |
Two things trip developers up. First, scopes are requested at install, so a merchant sees the full list on the consent screen. Second, changing scopes later forces existing merchants through a re-authorisation flow. That is why scope choices are an architecture decision, not a line of config you edit casually.
Why Shopify is pushing apps from write to read
Shopify has been explicit that apps should request the minimum scopes needed. The pressure comes from three directions.
- Security. A write scope is a live key to merchant data. If your token leaks, an attacker can edit products, refund orders or change customer records. A read scope limits the blast radius.
- App review. Shopify's reviewers check that every requested scope maps to a visible feature. Unused write scopes are a common reason apps get sent back for changes.
- Merchant trust. The install screen lists your scopes. Merchants and their agencies read it. An app asking for
write_orderswhen it only displays analytics looks suspicious and loses installs.
There is also a practical angle: fewer scopes mean fewer edge cases. Every write scope you hold is a code path you must test, secure and support.
How to audit which scopes your app really needs
Start from features, not from code. List what the app does in plain language, then map each feature to the smallest scope that supports it.
- Inventory your features. Write down every screen and background job. "Dashboard showing product counts" is a read feature. "Bulk price update" is a write feature.
- Trace each API call. Search your codebase for GraphQL and REST calls, then record the scope each one needs. Admin API calls fail without the matching scope, so this list is your ground truth.
- Flag unused scopes. Any scope with no matching call is a candidate for removal. This is usually where the quick wins are.
- Check webhooks and jobs. Background syncs often hold write scopes they no longer use after a refactor.
- Separate optional features. If a feature is behind a plan tier or a setting, consider requesting its scope only when the merchant enables it.
A simple spreadsheet works: feature, API call, required scope, current scope, action. Most apps find two to five scopes they can drop.
If you would rather have this audited by people who do it often, our Shopify app development service covers scope reviews, app review prep and custom private apps.
Downgrading scopes without breaking existing installs
This is the part teams get wrong. You cannot simply edit your scope list and redeploy. Existing merchants still hold tokens with the old scopes, and your app config, your code and Shopify's records must agree.
Step 1: Confirm nothing depends on the write scope
Before you remove write_products, prove no live code path writes products. Check scheduled jobs, webhook handlers, admin actions and any third-party integration that calls your app.
Step 2: Update the app configuration
Change the requested scopes in your app config (the shopify.app.toml file for Shopify CLI apps, or the Partner Dashboard for older apps). Keep the list ordered and documented.
Step 3: Handle re-authorisation
When scopes change, Shopify requires affected merchants to grant the new set. Design for this: detect the missing scope, show a clear in-app prompt explaining what changed and why, and link to the re-auth flow. Do not let the app fail silently.
Step 4: Degrade gracefully
If a merchant has not re-authorised yet, your app should still work in read-only mode where possible. Show a banner instead of throwing errors.
Step 5: Test on a development store
Install on a fresh development store, run every feature, and confirm no API call returns a permission error. Then test an upgrade path from an old install.
Checklist before you ship a scope change
- Every remaining scope maps to a shipped feature
- No code path calls an API without its scope
- Re-authorisation prompt is clear and tested
- Read-only fallback works for un-migrated merchants
- App review notes explain the scope change
- Support docs and the listing are updated
Scopes, app review and merchant trust
Scope hygiene pays off beyond security. Reviewers move faster when your requested scopes obviously match your listing screenshots. Merchants approve installs faster when the consent screen is short. And when a merchant's agency audits your app, a tight scope list is evidence you handle data carefully.
Keep a short internal note for each scope: what feature needs it and when it was last reviewed. Revisit it whenever you ship a feature or remove one. Scope creep is gradual — a write scope added for a one-off migration tends to stay for years.
When to bring in a Shopify app development partner
Trim scopes yourself if you have one app and a clear codebase. Bring in help when you have several apps, a legacy codebase with unclear API usage, an app review rejection tied to scopes, or a migration from REST to GraphQL where scope requirements shift.
We build and maintain Shopify apps, including private apps and integrations, and we handle scope audits, re-authorisation flows and app review prep. See our Shopify app development service or get in touch with your current scope list.
Related reading
- Trend-to-Store: A Shopify App Idea That Turns Search Trends Into Products, Content and Prices
- Mobile App Development Security Best Practices: 2026 Checklist
- Shopify POS UI Extension Cart Mutations: Fix Rejected Writes
- Shopify App Access Scopes: Write to Read Done Right
- Shopify Custom App Creation: A Step-by-Step Build Guide
Frequently asked questions
What is the difference between read and write scopes in Shopify?
Read scopes let your app view data, such as products or orders. Write scopes let it create, update or delete that data. Write access normally includes read access for the same resource, so requesting write when you only display data grants more power than you need.
Why does Shopify want apps to downgrade from write to read?
Because unnecessary write scopes increase security risk, slow down app review and reduce merchant trust. If a token leaks, a write scope lets an attacker change merchant data. Shopify's reviewers also expect every requested scope to map to a visible feature.
Will changing my app's scopes break existing installs?
It can, if you do not plan for re-authorisation. When scopes change, affected merchants must grant the new set. Detect the missing scope, show a clear prompt, and keep the app working in read-only mode until the merchant re-authorises.
How do I find out which scopes my Shopify app actually uses?
List your features, then trace every Admin API call in your codebase and record the scope each one requires. Any requested scope with no matching call is a candidate for removal. Include webhooks and scheduled jobs in the audit.
Can I request a scope only when a merchant enables a feature?
Yes. Optional or plan-gated features can request their scopes at the point the merchant turns them on, rather than at install. This keeps the initial consent screen short and the review simpler.
Do unused scopes cause app review rejections?
They are a common reason apps are sent back for changes. Reviewers check that each scope supports a feature shown in your listing and screenshots. Removing unused scopes usually speeds up approval.
Need your Shopify app scopes audited?
Send us your current scope list and what your app does. We will tell you which scopes you can drop, and handle the re-authorisation flow and app review prep if you want us to.