Scoped API keys
Keys that name what they may do, checked on the request rather than in the docs.
An API key that can do everything is a key you cannot safely put anywhere. Scopes make a key narrow enough to be useful in the places you actually need one.
How it works
- A key declares its scopes:
read_orders,write_orders,read_analytics. - Every protected endpoint names the scope it requires, and the check happens on the request.
- A key without the scope is refused, whatever else it is allowed to do.
It fails closed, which is the unusual part
A protected endpoint added without declaring a required scope does not quietly allow the request. It refuses it and logs a misconfiguration.
That is deliberate and it is the opposite of the common default. If the rule is missing, the answer is no — because the alternative is an endpoint that is accidentally public and gives no sign of it until somebody finds it.
Practical advice
Give a public-facing front end a read key and keep write keys server-side. A key shipped in browser JavaScript is a key you have published, and scoping it read-only is what limits the damage of doing so.
What it does not do
Scopes are not per-record permissions. A key with read_orders can read your orders — all of them — not a subset.
Stop reconciling stock by hand
One catalogue, six channels, one stock figure that stays right.