Developers

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.