What you are granting

The consent screen lists exactly what an app will be allowed to do. This page helps you read it.

The most important rule

The consent screen says this, and it is worth reading twice:

"An app can never do more than you can. Anything your role lacks is not granted, even if ticked."

Which means an app is bounded by two things, not one:

1. the permissions you ticked on the consent screen, and
2. your current role on this store.

And the second is checked per request, not captured at install time. So if the person who installed the app is later demoted to Viewer, the app loses write access on the next request — with nobody having to uninstall anything.

Two practical consequences:

• Someone on a low role cannot over-grant by accident. Ticking every box still grants nothing they do not themselves have.
• An app can stop working with nobody having touched it. If an app suddenly reports permission errors, check the role of whoever installed it.

The permissions, in plain language

The consent screen shows no technical codes. It shows sentences like these:

View	Change
View your products	Create and edit your products
View your orders	Create and edit your orders
View your customers	Create and edit your customers
View your discounts	Create and edit your discounts
View your blog	Create and edit your blog
View your pages	Create, edit and publish your pages
View your media library	Upload to your media library
View your theme	Change your theme
View your webhooks	Register and edit webhooks
View your integrations	Change your integrations
View your custom code	Change your custom code

And the store-level ones:

Permission	Means
Change your store settings	Can edit the Settings screens
Export your store content	Can download the whole site's content
See who works on your store	Can read the member list
Invite and remove people from your store	Can change the member list
Change what each role can do on your store	Can edit role definitions

The ones worth a pause

"Create, edit and publish your pages" — note publish. This app can put content on your live storefront, not merely edit a draft.

"Change your custom code" — custom code runs on every page you serve. In practice this permission lets the app run arbitrary code on your storefront.

"Invite and remove people from your store" and "Change what each role can do" — these two reach the permission system itself. Very few apps need them.

"View your customers" — this is other people's personal data. Read the app's privacy policy first.

None of this makes those permissions bad — an app that builds landing pages needs to publish pages. It means they are worth stopping on and asking what this particular app needs them for.

Unticking things

You can tick and untick individual lines: "Untick anything you would rather not grant. The app may not work fully without it."

If you withhold something the app genuinely needs, what you get is a feature that does not work, rather than a clear explanation. The app is not told which permission you withheld — it only learns when a call is refused.

A well-written app degrades gracefully. A poorly written one looks broken. If you withhold something and then see odd behaviour, try removing and reinstalling with the full set to confirm the cause.

There is no "what am I granting" screen after installing

Once installed, nothing tells the app exactly which permissions it holds — and there is no endpoint for it to ask. It finds out when a call is refused.

That is a documented, deliberate limitation rather than an oversight. See Build an app.

For you it means: if you cannot remember what you granted, the reliable way to find out is to remove and reinstall, reading the consent screen carefully.

Apps that run code on your pages

The Runs code badge on an app card is a separate kind of permission, not in the list above. It means the app ships JavaScript that runs on your published pages.

The platform can check the size and format of that code, but it cannot check what the code does. The control on that is the version review, and it is the only one — nothing can automatically prove the behaviour of a piece of code.

Which is why the badge appears before you install, not after.