Token lifetimes, error codes, app verification, etc.
Scope | Description | Info |
|---|---|---|
profile | Access to /api/users/current | |
offline_access | Issues refresh tokens for PKCE only apps | |
policy | Access to /api/escalation-policies | |
schedule | Access to /api/schedules | |
source | Access to /api/alert-sources | |
monitor | Access to /api/uptime-monitors | |
action | Access to /api/alert-actions | |
connector | Access to /api/connectors | |
maintenance | Access to /api/maintenance-windows | |
report | Access to /api/reports | |
template | Access to /api/incident-templates | |
service | Access to /api/services | also grants access to manage subscription of current user |
status_page | Access to /api/status-pages | also grants access to manage subscription of current user |
team | Access to /api/teams | |
user | Access to /api/users | |
alert | Access to /api/alerts | |
incident | Access to /api/incidents | also grants access to manage subscription of current user |
By default each scope grants read permissions to the described resource.
You may request write (granting you read, create and edit permissions on the resource) as well as delete permissions (granting you read, create, edit and delete permissions on the resource).
Examples:
service | grants GET on /api/services |
service:r | same as service |
service:w | grants GET, POST, PUT on /api/services |
service:d | grants GET, POST, PUT, DELETE on /api/services |
You may request multiple scopes by separating them with a space.
Like so:
profile service:w offline_accessCode | HTTP Status Code |
|---|---|
invalid_request | 400 |
invalid_scope | 400 |
access_denied | 400 |
server_error | 500 |
unsupported_grant_type | 400 |
invalid_grant | 401 |
Type | Lifetime |
|---|---|
code | 2 minutes |
access_token | 1 hour |
refresh_token | 1 year |
refresh_token per app per user | max. 10, if exceeded oldest refresh_token is automatically revoked |
refresh token requests | do not refresh a token more than once per 5 minutes |
request rate limits |
If you are building a backend application and it is verified, your refresh_token lifetime may be changed so that they never expire. Please reach out to us.
We would love to hear about and verify your applications, feel free to reach out to us, as soon as you are ready.
Do not rely on a users email address without being sure it is verified, or your application might be open to attacks where the email address is mimiced on the authorization server.
Use the username or the user's id to verify account ownership in your app.