Token lifetimes, error codes, app verification, etc.
ilert OAuth2 scopes
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 | also grants access to subresources /api/users/{id}/contacts and /api/users/{id}/notification-preferences |
alert | Access to /api/alerts | |
incident | Access to /api/incidents | also grants access to manage subscription of current user |
metric | Access to /api/metrics | |
metric_source | Access to /api/metric-data-sources |
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_access
OAuth2 endpoints overview
Method | Url |
---|---|
| |
| |
| |
|
OAuth2 error codes overview
Code | HTTP Status Code |
---|---|
invalid_request | 400 |
invalid_scope | 400 |
access_denied | 400 |
server_error | 500 |
unsupported_grant_type | 400 |
invalid_grant | 401 |
OAuth2 lifetimes and numbers
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 | usual request limits apply |
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.
App verification
We would love to hear about and verify your applications, feel free to reach out to us, as soon as you are ready.
Other info
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.
Last updated