Skip to main content
A scope says what the holder may do, never who they are. New functionality gets a new scope rather than widening an existing one, so a token can never quietly gain access a seller did not approve. The ones marked ❌ are ours for now. Asking for one is refused at the token endpoint with invalid_scope: a client-credentials request straight away, and an authorization code when you exchange it. The consent screen does not check this yet, so a seller can be shown one and approve it — but no token is ever issued with it. Ask only for the ✅ ones. Why each of them, and which could open up →

Two checks, not one

1

Does the token carry the scope?

Your token carries the union of what every business that connected you agreed to. Without the scope at all, the answer is 403.
2

Did this business grant it?

Checked again per request, against what that business ticked. A shop that granted you reading answers 403 to a write even when another shop granted you writing — the token alone cannot answer “may I do this here”.
Narrowing or withdrawing a grant takes effect immediately. There is no token to wait out.

Asking for fewer

Ask only for what you use. A seller looking at a consent screen reads the list, and a shorter one is approved more often than a longer one.