Scopes

What a key may do is decided entirely by the scopes on that key. There is no second permission layer underneath.

A call whose key lacks the scope is refused with 403 INSUFFICIENT_SCOPE, and the message names the scope that is missing. Give a key the narrowest set that does its job: a key that only reads cannot delete a meeting, whatever else goes wrong.

Four scopes are marked sensitive and are never part of a preset. Whoever creates the key has to select them deliberately.

employees:read1 endpoint

GET/v1/employees

employees:writeSensitive1 endpoint

POST/v1/employees

meetings:deleteSensitive1 endpoint

DELETE/v1/meetings/{meeting_id}

meetings:read2 endpoints

meetings:write4 endpoints

minutes:read1 endpoint

GET/v1/meetings/{meeting_id}/minutes

projects:read1 endpoint

GET/v1/projects

projects:writeSensitive2 endpoints

templates:read1 endpoint

GET/v1/templates

transcript:read1 endpoint

GET/v1/meetings/{meeting_id}/transcript

usage:read1 endpoint

GET/v1/usage

vocabulary:read1 endpoint

GET/v1/vocabulary

vocabulary:writeSensitive2 endpoints

An invalid request is refused before the scope is checked

Request validation runs first, so a call with both a broken body and a missing scope answers 400 INVALID_REQUEST, not 403 INSUFFICIENT_SCOPE. Fix the body, then read the status again.