Refresh tokens, rotate secrets and revoke access
Implement token lifecycle and stop access when consent is revoked.
Editorial update: October 30, 2026In this guide
Token lifetimes
| Item | Current behavior |
|---|---|
| access_token | Valid for one hour after issuance. |
| refresh_token | Valid for 30 days and replaced on each refresh. |
| Idle grant | Revoked after 90 days without use. |
| Reused retired refresh token | Revokes the mailbox grant; obtain new consent. |
Refresh server-side
Refresh-token request
curl -i 'https://raselmail.com/api/v1/oauth/token' -u "$RASEL_CLIENT_ID:$RASEL_CLIENT_SECRET" --data-urlencode 'grant_type=refresh_token' --data-urlencode "refresh_token=$RASEL_REFRESH_TOKEN"Atomically replace both access_token and refresh_token. Serialize refreshes for a grant in your application; using the old token again is not an ordinary retry. On invalid_grant, stop refreshing and obtain consent again.
Revoke a connection
Revoke with a token
curl -i 'https://raselmail.com/api/v1/oauth/revoke' -u "$RASEL_CLIENT_ID:$RASEL_CLIENT_SECRET" --data-urlencode "token=$RASEL_REFRESH_TOKEN" --data-urlencode 'token_type_hint=refresh_token'Owners can revoke a connection from Applications at any time. Successful revocation does not prove a token was valid beforehand. Rotating client_secret revokes all app grants; it is different from refreshing one user’s access token.