Skip to main content
All CollectionsDeveloper APIAPI Information
What developer scopes are available?
What developer scopes are available?

Developer API scope information

Updated over a week ago

Scopes determine which permissions the Developer API Application wants to obtain from the user's account. Scopes do not override the user's account permissions. In order to access a resource via the API, the API application must have the appropriate scope issued to the API Application and the user must have the appropriate permissions on the user account. More scopes are planned for the future so check back periodically when the API Version changes to see the new scopes that are available.



The API Application may request the following scopes:

read_organization
Allows the API application to read global information about the organizational structure.

add_to_organization
Allows the API application to add new and update existing information within the subscription.

manage_organization
Allows the API application to perform just about every action on behalf of the subscription.

read_personal_schedule
Allows the API application read-only access to the user's personal schedule and assignments.

manage_personal_schedule
Allows the API application to fully manage the user's personal schedule and assignments.

read_personal_account
Allows the API application read-only access to the user's personal account information and settings.
manage_personal_account
Allows the API application to fully manage the user's personal account information and settings.


These scopes are based on the documentation available at http://www.horizonwebref.com/developer



API Developers should build their applications to appropriately handle missing scopes or scopes the user refuses to provide. For example, an API Application may request the scopes read_personal_account and manage_personal_account from the user via the oAuth2 resources. However, the user, during the authorization stage, may refuse to allow the manage_personal_account scope and only allow the read_personal_account scope. In this case, the API application should accommodate and adjust any future API calls for that user based on the scopes that the user actually provided.

As an additional example, the API application may request the manage_personal_account and the manage_organization scopes from the user. If the user has only General Member permissions and has no permissions on their account to manage their organization, they will be unable to provide the API application the manage_organization scope. Similar to above, the API application should appropriately handle this based on the scopes that are actually returned to the API application after the oAuth2 authorization stages.

Did this answer your question?