Token lifetimes, error codes, app verification, etc.
ilert OAuth2 scopes
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
GET
POST
POST
POST
OAuth2 error codes overview
invalid_request
400
invalid_scope
400
access_denied
400
server_error
500
unsupported_grant_type
400
invalid_grant
401
OAuth2 lifetimes and numbers
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.
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