Skip to Content
Scopes

Scopes

The API uses a least-privilege scope taxonomy: exactly one read scope per data domain, and no scope maps to more than one domain. v1 is read-only — there are no write scopes.

Each scope authorizes a single domain and limits responses to a fixed field projection. The same field set is returned across single-record, list, and aggregation responses. Fields outside the projection — and all internal fields such as userId and credential hashes — are never returned.

The 13 scopes

ScopeData domainProjected fields
read:health-datahealth-data (vitals/readings)id, type, value, unit, timestamp, source
read:aggregationsaggregations / summariessummary shape only (derived)
read:trendstrendsbucketized trend points only (derived)
read:symptomssymptomsid, description, severity, timestamp
read:medicationsmedications & adherenceid, name, dosage, frequency, condition, pattern
read:conditionsconditionsid, name, severity, sinceDate
read:allergiesallergiesid, name, severity, sinceDate
read:appointmentsappointmentsid, title, dateTime, specialty, location
read:weightweightid, weightKg, date
read:moodmoodid, mood, note, timestamp
read:reportsreportsid, generatedAt, dateRange, summary
read:profileprofile (demographics)name, gender, dateOfBirth, bloodType
read:ehrEHR-derived dataid, resourceType, summary, timestamp

How scopes are enforced

On every authenticated /api/v1 request, the platform:

  1. Resolves the single scope the endpoint requires.
  2. Rejects with INSUFFICIENT_SCOPE (HTTP 403) if the token lacks that scope, or presents a scope not in this taxonomy. The error names the missing scope.
  3. Rejects with CONSENT_REQUIRED (HTTP 403) if no active consent grant covers that scope for the requesting client and target user.

A scope can never reach data outside its own domain.

Requesting scopes

Request only the scopes your app needs. Users can approve a subset, so design your app to degrade gracefully when some requested scopes are not granted.