Session Revoked
session_revoked401
This session was revoked. Sign in again to get a new one.
What this means
The session token in the request matches a real session record, but that session has been marked as revoked. We refuse it and require a fresh sign-in. Revocation usually happens because the user signed out, an admin invalidated the session (security event, account closure), or all sessions were rotated as part of a password or account-level change.
When you'll see this
- The user signed out in one tab and a different tab tried to use the same session.
- An admin invalidated sessions for the account (security incident, suspicious activity).
- The user changed their email or other security-critical detail, triggering session rotation.
- A "sign out everywhere" action was performed on the account.
Learn more about how this works
Session revocation is the dashboard-side equivalent of API-key revocation. We keep the record (for audit purposes) but mark it inactive. Subsequent uses return this error rather than session_not_found, because the session did exist — it was just deliberately killed. From the user's perspective, the action is the same: sign in fresh.
In practice: if a user sees this unexpectedly, they should sign in and consider whether they recognize the cause. Unexpected revocations sometimes indicate a security event worth investigating in the account's audit log.
Example response
{
"success": false,
"error": "session_revoked",
"message": "This session has been revoked. Please sign in again.",
"details": [],
"retry_after": null,
"doc_url": "https://docs.asterwise.com/reference/errors/session_revoked",
"request_id": "req_01HXYZABCDEFGH",
"timestamp": "2026-05-25T12:34:56Z"
}
- Sign in fresh at asterwise.com/signin.
- If this was unexpected, check the dashboard's audit log for any sign-out-everywhere or admin-initiated events around the time of revocation.
- If you suspect unauthorized access triggered the revocation, rotate any API keys on the account immediately.
Same redirect-to-signin pattern as session_not_found. The distinction matters mostly for telemetry — a spike in session_revoked events points to an account-security action.
Python:
Production handler
- Python
- TypeScript
import httpx
import logging
logger = logging.getLogger(__name__)
def call_dashboard_endpoint(url, session_token):
response = httpx.get(
url,
headers={"Authorization": f"Bearer {session_token}"},
timeout=15,
)
if response.status_code == 401:
body = response.json()
if body.get("error") == "session_revoked":
logger.warning(
"Session was revoked — possible security event",
extra={"request_id": body.get("request_id")},
)
return {"ok": False, "redirect_to": "/signin"}
response.raise_for_status()
return {"ok": True, "data": response.json()}
async function callDashboardEndpoint(url: string, sessionToken: string) {
const response = await fetch(url, {
headers: { Authorization: `Bearer ${sessionToken}` },
});
if (response.status === 401) {
const body = await response.json();
if (body.error === "session_revoked") {
console.warn("Session was revoked — possible security event", {
request_id: body.request_id,
});
return { ok: false, redirectTo: "/signin" };
}
}
if (!response.ok) throw new Error(`HTTP ${response.status}`);
return { ok: true, data: await response.json() };
}
Avoid this error by
- Sign out cleanly when leaving a session, especially on shared devices. This is the most common cause of legitimate
session_revokedevents. - Don't rely on multi-tab session persistence across long idle gaps. Tabs can outlive sessions.
- For automation that uses sessions (rare), handle revocation gracefully — redirect to fresh sign-in rather than retrying.