Should Shopify merchants grant an app access to customer data before it needs it?
You are installing an app to solve one job. Maybe you need to add reviews, check inventory, or improve your email flows.
Then the install screen asks to view customers, orders, addresses, email addresses, and phone numbers. The app says it may need these later.
Pause there.
You do not need to grant customer access because an app might use it one day. Shopify's guidance is that apps should request only the data they need to function. That is a useful rule for merchants too: approve access for the feature you are turning on now.
Start with the job, not the permission list
Before you install an app, write down what you expect it to do in one sentence.
For example:
- “I need this app to show product reviews on product pages.”
- “I need this app to send a post-purchase email.”
- “I need this app to help reconcile orders.”
Then compare that job with the access request on Shopify's install screen. Shopify shows what store data an app wants to view or edit. That can include customers, orders, products, marketing, and analytics. It also shows when an app requests access to personal data, along with its privacy policy.
A request is not automatically wrong because it includes customer data. A post-purchase email tool may need customer details to do the job. But the developer should be able to explain the connection in plain language.
If you cannot see why an app needs an area of your store, ask before installing. A clear question is enough:
Which feature needs customer access, which customer fields does it use, and can I enable that access later?
The answer should name a feature. “For future improvements” is not a feature.
Customer data can sit behind more than one permission
It is easy to look for a permission labelled “customers” and stop there. That is not enough.
Shopify notes that customer data can also appear in orders, draft orders, fulfillments, abandoned checkouts, and store comments. Some of those records can contain protected customer fields.
So an app asking for order access may also be asking for a route to customer information. Read the order request with the same care you would give a direct customer request.
This matters most when the app asks for broad access and its core job is narrow. Say you install a tool that checks product-page content. It may need product access. It is reasonable to ask why it also needs orders or customers.
There may be a good reason. You should hear it before you approve it.
Treat older order history as a separate question
Shopify's `read_orders` and `write_orders` scopes cover the most recent 60 days of orders by default. Access to older, past, and future orders needs `read_all_orders`.
Shopify reviews that broader scope to check that it is necessary for the app to work.
That does not mean every app requesting order history is unsafe. It means the request deserves a more specific question:
Why do you need orders older than 60 days for the feature I am using?
An accounting workflow may have an answer. A feature based on recent fulfilment activity may not need years of history. The point is not to guess. It is to make the app connect the data it wants to the work it will do.
Ask for optional access when the feature is optional
Shopify gives developers a way to handle this properly. An app can request required scopes at installation, then request `optional_scopes` later when a merchant turns on an add-on feature.
You can decline optional access. You can also revoke it later.
That creates a cleaner sequence:
1. Install the app with access needed for its basic job. 2. Turn on an extra feature only if you want it. 3. Review the new access request at that point. 4. Approve it only if the feature needs it.
This is better than approving a long permission list in advance because you expect to use more of the app later. You may never turn on those features. The app does not need that data sitting available in the meantime.
Permission is not the same as protected-data approval
Some customer fields have extra controls. Shopify treats name, address, email, and phone as protected customer fields for public apps.
A public app must request these fields individually, explain why it needs them, meet Shopify's requirements, and go through a data-protection review. An app can declare relevant scopes before that approval, but on non-development stores Shopify will not return protected customer data until it has been approved.
That is a useful safeguard. It is not a reason to stop reviewing permissions yourself.
Approval tells you Shopify has a process around protected data. It does not answer the store-specific question: does this app need this data for the work you asked it to do?
Check access after you install
Permissions are not a one-time decision buried in an old install screen.
Open Settings → Apps in Shopify. You can review an app's permissions and its recent view and edit activity by store area. Shopify also marks permissions an app has not used in the last 30 days under Unused access.
You can check this in under a minute.
Look at one app you installed a while ago. If it has unused customer or order access, decide whether you still need the app, the feature, or that access. If the app uses access you do not understand, ask the developer for an explanation.
This review is especially useful after changing tools. Stores often keep an old app installed because it once handled a small job. Meanwhile, it may still have access you no longer want to grant.
Build trust by asking for less
We made this choice with Descriva. We ship it without theme-write permission on purpose.
That means fewer permissions for a merchant to assess and less to trust. There is a trade-off. If a merchant needs a custom `llms.txt` file in their theme, we provide a template for them to paste. Then Descriva reads the live URL afterwards instead of assuming the change worked.
That is less convenient than silently writing to a theme. It is also more honest about what the app can do.
Every developer makes choices like this. A well-designed app can separate its core job from extra features, ask later when extra access is needed, and explain the reason without vague language.
You can expect that standard even if you never write code.
If you uninstall, follow up on deletion
Uninstalling removes the app from your Shopify store. It is still worth checking what happens to personal information the app collected while it was installed.
Shopify sends the developer a request to erase collected customer personal information 48 hours after uninstall. Shopify also says merchants need to contact the developer to confirm deletion.
If you remove an app that held customer data, send a short note to the developer. Ask them to confirm that customer personal information collected through your store has been deleted.
Keep the request simple and keep their reply with your store records.
A practical rule for your next install
Approve the minimum access needed for the feature you need today. If an add-on needs more later, it should ask then.
Be careful with customer and order access, since either can expose customer information. Ask direct questions about broad order history. Review unused access in Settings → Apps from time to time.
For your next app install, spend one minute matching each requested permission to a feature you plan to use.