Scopes & data classes

A key carries two independent kinds of permission, and a request must clear both.

1. Resource scopes — which endpoints

These are the ones in use across the API today:

attendance:read
attendance:write
events:read
events:write
lodging:read
members:read
members:write
org:read
registrations:read
registrations:write
sync:read
sync:write
units:read
units:write

2. Data classes — which fields

All three are off by default. Without them a key sees names, roles, and clubs — the roster shape, and nothing personal.

Class	Unlocks
`data:pii`	email, phone, date of birth, gender, username
`data:health`	dietary needs (which carry allergies)
`data:safeguarding`	background-check status

Some fields are never exposed at any class: password hashes, authentication ids, and session validity.

Reading: absent, not blank

A field outside your classes is left out of the object entirely, and the class is listed in redacted_classes. In CSV the column itself is missing. An empty dietary_needs would say “this child has no allergies”; an absent one says “you may not see allergies”. Those are very different claims.

Writing: refused, not ignored

Sending a field outside your classes is a 403 that names the field. We never accept a write and silently drop part of it — an integration that believes it recorded a birthdate and didn’t is worse than one that got an error.

The two axes are independent

data:safeguarding with members:read can read background-check status but not change it. members:write without the class can edit a member but not that field.