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

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

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

#1259: AWS Integrations

Change request updated