A browser never holds a venue key
A venue key authenticates a venue’s own server. Putting one in a browser hands every person who opens the developer tools a credential that configures your venue, so the operator door exists precisely so that never has to happen. The console at/developer uses it, and there is no build of that console
that accepts a key.
The two doors are also judged differently, because the requests differ. A key arrives with an
Authorization header and no Origin; a browser arrives with an Origin and no header. A write
from a browser with no trusted Origin is refused as origin_not_allowed, and a bearer header is
never accepted as an exemption from that check.
Every configuration call exists on both
Instruments, conditions, groups, routes, stages, providers and the firm’s accounts (issue, list, balance, reset, halt, resume, analytics) are reached at the same suffix under either prefix.POST /api/partner/venues/{venueId}/routes and
POST /api/operator/venues/{venueId}/routes create the same route, take the same body and the same
Idempotency-Key, and refuse the same things.
The reference lists the partner form of each of these. Swap the prefix and drop the bearer header to
read it as the operator call.
Six calls exist only on the session door
These are the calls made before a venue exists, or about the person rather than the venue. A key names a venue, so it could not express them even if a browser were allowed to carry one.
Issuing and revoking a venue key is session-only for the same reason in reverse: no key may mint
another key.