Skip to main content
A scope is written {resource}.{read|write}, and a .write scope always includes its .read. A GET or HEAD request needs the .read scope of its resource, any other method needs the .write one. Ask only for what your application calls. Users see every scope on the authorization screen, in the words of the second column, and they can untick them.

​
Available scopes

A route written with … covers everything that starts with it. The sharing and tag routes on a file entry are matched before the broad file-entries… line, so sharing a file needs sharing.write, not files.write.

​
Exceptions to the method rule

  • POST /file-entries/download-urls, POST /file-entries/sync-info and POST /file-entries/hash/check only read: files.read is enough.
  • GET /workspace/join/… joins a workspace: it needs workspaces.write.
  • analytics.read and notifications.read have no .write counterpart. Marking notifications as read or deleting them is not available to applications.

​
The sync API

The sync API (/api/v1/sync/…) mirrors the whole Drive tree, files and folders together, so it asks for both: It is not available to an application that works in its own folder, whatever its scopes.

​
Every token can read

GET /users/me, whatever its scopes. Use it to learn which account authorized you, and to check that a token still works.

​
What no application can have

  • *. There is no “everything” scope. Ask for what you use.
  • vault.read and vault.write. The Drime Vault is end-to-end encrypted and only Drime’s own apps can access it. This includes the Vault’s folder tree, users/{id}/folders?vault=1.
  • workspaces.*, for an application that works in its own folder: that folder lives in the user’s personal Drive.

​
Always refused

Whatever its scopes, a token never reaches the routes that manage the account itself: API tokens and sessions, e-mail address, password and two-factor settings, the sign-in routes, billing, settings, the admin area, the developer console and the OAuth endpoints. An application cannot create another token or widen its own access. A route that belongs to no resource above is refused too.

​
When a scope is missing

The status is 403. Tick the scope under Permissions in the console, then send your users through the authorization flow again: a token never gains a scope after it was issued. The Analytics tab of your application counts these refusals by scope. A route that is always refused answers 403 with: