Scopes

A scope is a permission token your integration asks the user (or themselves, for server-to-server) to grant. Each access token carries the list of granted scopes; each endpoint requires one.

Request multiple scopes by joining them with a single space:

scope=flights:read flights:write profile:read

Catalog

Scope	What it grants	Status
flights:read	List a user's flights; read scoring, metadata, summarised analysis; download the raw IGC file (planned endpoint)	Stable
flights:write	Upload IGC files to the user's logbook	Stable
flights:delete	Permanently remove flights	Stable, destructive
profile:read	Read display name, club, CIVL id, public-profile flag	Stable
profile:email	Read the account email address (in addition to profile:read)	Stable
profile:write	Update display name, club affiliation, license info	Planned
community:read	Read public community data (takeoff sites, leaderboards)	Planned

Restrictions

• Pending applications can only obtain read-only scopes (flights:read, profile:read, profile:email, community:read), and only for their own owner. Once an admin promotes the app to approved, it can request the destructive scopes from arbitrary users.

• API keys cannot grant flights:delete. The risk profile of a long-lived key bundled into a personal script is too high for a destructive scope — use OAuth for delete flows.

• Public clients (SPAs, mobile apps with no server-side secret) must use PKCE and cannot use client_credentials. They CAN request any scope via Authorization Code, subject to user consent.

Asking for fewer scopes later (downscoping)

When you refresh a token (grant_type=refresh_token) you may pass a scope parameter narrower than the original grant. The returned access+refresh pair will carry only the narrowed set, and the new refresh token cannot widen back. This is useful when you've decided your integration no longer needs (say) flights:write and you want to remove that capability without forcing a new user-consent screen.

You cannot widen a scope on refresh — the server will return invalid_scope. Get the user to re-authorise instead.

Consent screen

When a user authorises an app, they see a list of requested scopes with a short human description. The same scope catalog is applied identically on the server and the consent UI — partners cannot override the description.

Dangerous scopes (write, delete) are visually flagged.