> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshooting: support access (view-as) token failures

> Resolve support-access (view-as) link failures — SESSION_REVOKED, TOKEN_ALREADY_USED, MISSING_COOKIE, INVALID_TOKEN — and reclaim control of who can enter your workspace.

# Troubleshooting: support access (view-as) token failures

Support access (also called *view-as*) is the time-boxed door you open so
Devotel support can sign in as your workspace to help with an issue. You
control the whole lifecycle from **Settings → Security → Support access**:
grant a window (15 minutes to 24 hours), and Devotel support can open it
only while the window is live; deny or revoke at any point and every
active session ends with it.

The operator trades the grant for a short-lived, single-use link. This
page covers the failures that link can produce — the codes you may see in
a support ticket, and the codes your own audit log records when a link
attempt is rejected.

## Symptom

When Devotel support opens the access link, the attempt returns one of
these codes (all HTTP 401) or an HTTP 503:

```json theme={null}
{ "status": "error", "code": "SESSION_REVOKED", "message": "Impersonation session has been ended" }
```

| Code                        | Meaning                                                                                                                                                                                             | Whether retrying helps                                                                     |
| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| `INVALID_TOKEN`             | The link was expired, malformed, or forged — or, on the direct-exchange path, an access window you revoked. The rejection shape is uniform on purpose, so a link tells an attacker nothing.         | No — the same link always fails. A new window needs a new link.                            |
| `SESSION_REVOKED`           | You (or your workspace owner) ended support access after the link was issued. This rejection is recorded in your audit log as `auth.impersonation_exchange_rejected` with reason `session_revoked`. | No — it means revocation worked. Re-grant a window if support still needs in.              |
| `TOKEN_ALREADY_USED`        | Each link is single-use: once it opens a session, no second visit is accepted. Reusing a browser tab or a forwarded link hits this.                                                                 | Not with the same link — a fresh grant issues a fresh link.                                |
| `MISSING_COOKIE`            | The link stages its token in a five-minute, httpOnly cookie; the browser then has five minutes to consume it. A delayed click, or a browser that blocks cookies, arrives empty-handed.              | Yes, if within the five-minute staging window and cookies are allowed. Otherwise re-grant. |
| `SERVICE_UNAVAILABLE (503)` | The platform could not check the link's revocation state or its one-time-use guard — a transient internal fault, not a rejected token.                                                              | Yes — retry shortly; a 503 is never a security rejection.                                  |

## Fix steps, per code

1. **`INVALID_TOKEN` — issue a fresh link.** Grant windows are
   time-boxed, and the link inherits the window's expiry. The owner opens
   **Settings → Security → Support access** and grants a new window; the
   support session opens on that link. Retrying the old one is never
   useful.
2. **`SESSION_REVOKED` — confirm revocation was intended.** This code is
   your deny/revoke control working as designed: denying support access
   ends every active session and rejects even links issued before the
   deny. If support still needs access, re-grant a new window; if not,
   nothing to do.
3. **`TOKEN_ALREADY_USED` — treat it as a used link, or a leak.** One
   visit burns a link. If nobody on the support side opened it, treat a
   used-link rejection as a leak signal, deny support access in Settings →
   Security, and ask Devotel support to re-issue. Every rejection is
   audit-logged (below), so you can see where it was consumed from.
4. **`MISSING_COOKIE` — re-open within five minutes, or re-grant.** The
   staging cookie lasts five minutes and requires your browser to accept
   cookies from `orbit.devotel.io`. Corporate proxies and strict
   cookie-blocking browsers are the usual cause; re-open the link promptly
   or have the owner re-grant.
5. **503 — retry.** A 503 means the acceptance machinery could not run,
   so the platform refused rather than guess. Try again shortly; if it
   persists, report it — that is a platform fault, not an access problem.

## Revoking access

All support-access controls are tenant-owned and owner-gated, at
**Settings → Security → Support access**:

* The grant/deny toggle locks or unlocks the door — only the workspace
  **owner** can flip it (admins see the section read-only).
* **Deny access** ends every active support session at once and rejects
  any link issued before the deny.
* The **Active support sessions** list shows each live session with its
  recorded reason, start, and expiry; the **End session** control on a row
  stops that one session without closing the grant window.

## Audit trail

Every grant attempt — accepted or rejected — lands in your **Settings →
Audit log** (owners and admins only). Accepted attempts record
`auth.impersonation_consumed`, and rejected ones record
`auth.impersonation_exchange_rejected` with the real reason — including
`session_revoked` — alongside the acting operator and source IP. See the
[audit log guide](/guides/audit-log) for filters and export.

<Note>
  A revoked session rejects with `SESSION_REVOKED` on the browser-consume
  link but with the uniform `INVALID_TOKEN` on the direct-exchange call —
  both are recorded as `session_revoked` in your audit log. The uniform
  rejection shape is deliberate: a link of this class never tells an
  unsolicited caller which tokens once existed.
</Note>

## What to send support

If a link keeps failing and the cause matrix above does not settle it,
open a ticket with:

* The **error code** exactly as returned, and the **`request_id`** from
  the response's `meta` block.
* Your **tenant ID** (Settings → Organization).
* Roughly when the window was granted and for how long.

Never paste the access link itself into a ticket — it is a credential
until it is used or expires.

## Coverage map

Do not confuse support-access failures with these lookalikes:

* [ACCOUNT\_LOCKED at dashboard sign-in](/troubleshooting/account-locked-login) —
  the 403 login lock on your own dashboard users (brute-force lockout,
  owner/admin freeze, or a suspicious-login hold). A locked member account
  is unrelated to the support view-as link.
* [Authentication, key mode, and IP allowlist](/troubleshooting/auth-and-api-keys) —
  API-key rejections (`INVALID_API_KEY`, `EXPIRED_TOKEN`, `WRONG_KEY_MODE`,
  `IP_NOT_ALLOWED`) and SAML/SCIM gates. The `INVALID_TOKEN` here applies
  only to support-access links, never to your API keys.

## See also

* [Audit log](/guides/audit-log) — filters, export, and the webhook
  stream for your SIEM.
* [Error codes reference](/reference/error-codes) — the full
  authentication failure group.
* [Glossary](/reference/glossary) — the *Support access (view-as)* entry.