switching clears the token & responses
No token
22

Managing your active sessions

Sessions & devices

A user reviews where they're signed in and revokes sessions. Counterpart to trusted-device management (scenario 23) — this lists where you are signed IN, that lists what is TRUSTED.

  1. GET /v1/me/sessions — active sessions (the current one has current: true)
  2. DELETE /v1/me/sessions/{sessionId} — revoke a specific session (e.g. a lost device)
  3. DELETE /v1/me/sessions — 204; sign out EVERY OTHER device in one call, keeping this one. Idempotent, no step-up
  4. POST /v1/auth/logout — sign out the current session · POST /v1/auth/logout/all — everywhere
GET/v1/me/sessionsauthList my sessions

The current session has current: true — use it to avoid revoking the device you're on by accident — or use “sign out every other device” below, which cannot revoke it.

ℹ︎Field guide — what each value means & where it comes fromno inputs

No request body, no path/query params, and no caller-set headers. It only needs the tester's bearer access token plus the gateway-injected x-gateway-context (both handled for you); a missing/invalid context returns 403. Returns the list of your active sessions with the current one flagged.

Bearer token
→ GET https://api.kerja.team/v1/me/sessions
↩︎Response guide — what comes back & what each value means8 fields

200 OK with the standard { data } envelope, where data is an ARRAY of the caller's active session objects (each item documented below via "data[]." paths). No special response headers. An empty array is returned if there are no active sessions.

data[].idstringalways
The session's unique identifier. Pass as {sessionId} to DELETE /v1/me/sessions/{sessionId} to revoke that specific session.
data[].ipstringalways
The IP address recorded for the session, e.g. "203.0.113.4". A UI can show it to help the user recognise the device/location.
data[].userAgentstringalways
The User-Agent string captured for the session (e.g. browser/OS). Displayed so the user can identify which device the session belongs to.
data[].amrarrayalways
Authentication Methods References array — the methods used to establish this session (e.g. ["pwd","otp"]). Indicates how strongly the session was authenticated.
data[].amr[]enumalways
An individual authentication method reference value within the amr array.
  • pwd — Session was authenticated with a password (primary credential).
  • otp — Session was authenticated with a one-time password / TOTP (MFA factor).
data[].createdAtISO-8601always
Timestamp when the session was created (login time). Display as the session start.
data[].lastUsedAtISO-8601always
Timestamp the session was most recently used. A UI can show recency / sort sessions by activity.
data[].currentbooleanalways
Flags whether this item is the session making the request ("this device"). Used so the UI can mark it and avoid accidentally revoking the active session.
  • true — This is the caller's own current session — do not offer/perform self-revocation by accident.
  • false — A different session belonging to the user; safe to revoke remotely.
DELETE/v1/me/sessions/{sessionId}authRevoke one session

Revoking a session does NOT untrust its device — sessions and device trust are separate lifetimes, so the next login from that browser still skips the device challenge. To stop that, untrust the device too (scenario 23).

Path parameters
ℹ︎Field guide — what each value means & where it comes from1 field

No request body. Revokes one of the caller's own sessions; the only caller-supplied input is the sessionId path param. Auth is still required (the tester supplies the access token and the gateway injects x-gateway-context identity).

sessionIdpathUUIDrequiredfrom a response
The id of the session to revoke. You do not type this yourself; obtain it from a prior GET /v1/me/sessions response (the `id` field of the session entry you want to revoke). Must be a valid UUID or the call returns 422; if it is not one of the caller's own sessions the call returns 404.
Bearer token
→ DELETE https://api.kerja.team/v1/me/sessions/{sessionId}
↩︎Response guide — what comes back & what each value meansno body

200 OK returning the { data } envelope with an empty data object ({ "data": {} }) — no body fields and no notable response headers; signifies the named session was revoked.

DELETE/v1/me/sessionsauthSign out every other device

204 — every session but the calling one is revoked (possibly none). Idempotent, and NO step-up: the caller only loses what someone on another device holds. 403 when the context carries no acting session (sid) — with nothing to keep, it FAILS CLOSED rather than revoking everything (the dev gateway-token minter omits sid, so locally this may be the answer you see). Audited sessions_revoked_others. Device trust is untouched — untrust devices separately (scenario 23).

ℹ︎Field guide — what each value means & where it comes from1 field

Signs the caller out of every OTHER device (E-20): every session but the calling one is revoked. No body, no parameters, NO step-up — the caller only loses what someone on another device holds. 204, idempotent (possibly nothing revoked). The session to KEEP is the one named by the sid in the verified gateway context; a context with no acting session is refused 403 — with nothing to keep, the call fails closed rather than revoking everything (contrast DELETE /v1/me/devices, which untrusts everything in that case). Device trust is untouched — untrusting is DELETE /v1/me/devices. Audited sessions_revoked_others. Walk-through: scenario 22.

sidheaderclaimrequiredgateway-injected
The session id inside x-gateway-context — the session that SURVIVES. Not typed: the gateway stamps it from your bearer. Missing (e.g. an operator or act-as context, or a locally minted context without sid) → 403 forbidden.
Bearer token
→ DELETE https://api.kerja.team/v1/me/sessions
↩︎Response guide — what comes back & what each value meansno body

204 No Content — no body. Signs the caller out of every OTHER device: every session but the calling one is revoked (possibly none); idempotent and no step-up, since the caller only loses what someone elsewhere holds (scenario 22). 403 forbidden when the gateway context is missing or has no acting session (no sid) — with nothing to keep, the call fails closed rather than revoking everything. Device trust is untouched. Audits sessions_revoked_others.

POST/v1/auth/logoutauthLogout (current session)

No body. Needs the sid the gateway puts in x-gateway-context. Clears the refresh_token cookie.

ℹ︎Field guide — what each value means & where it comes fromno inputs

No request body. Revokes the current session identified by the gateway context and clears the refresh_token cookie. The caller supplies no fields, path params, query params, or required headers — the tester sends the access token (Authorization) and the gateway injects x-gateway-context including the session id (sid). Returns 200 with { "data": {} }; fails 401 if there is no session id in the gateway context, or 403 if the gateway context is missing/invalid.

Bearer token
→ POST https://api.kerja.team/v1/auth/logout
↩︎Response guide — what comes back & what each value meansno body

Returns 200 OK with the standard { data } envelope, where data is an empty object ({}) — there are no body properties to consume. The meaningful side effect is the Set-Cookie response header, which clears the refresh_token cookie (revoking the current session from the gateway context). The tester should treat this purely as a success/failure signal and drop any stored refresh token.

POST/v1/auth/logout/allauthLogout everywhere

No body. Revokes every session for the user and clears the refresh_token cookie. ONE SESSION COVERS EVERY APP, SO SIGNING OUT OF ONE SIGNS OUT OF ALL OF THEM (scenario 20): revoking the session kills every renewal chain under it — each open app fails its next POST /v1/auth/apps/{clientId}/refresh rotation, and any access token still in flight dies at its next /internal/validate hop or at expiry, whichever comes first. THERE IS NO PER-APP LOGOUT, and that is the same one-session model that makes the tenant switch (scenario 21) session-wide.

ℹ︎Field guide — what each value means & where it comes fromno inputs

No request body, path params, query params, or caller-set headers. It requires only an authenticated request: the tester sends the captured accessToken (Authorization) and the gateway injects x-gateway-context identifying the user; the endpoint revokes every session for that user and clears the refresh_token cookie. Returns 200 with an empty data object.

Bearer token
→ POST https://api.kerja.team/v1/auth/logout/all
↩︎Response guide — what comes back & what each value meansno body

Returns 200 OK with the { data } envelope, but data is an empty object ({ "data": {} }) — there are no body properties to consume. The notable side effect is the response header Set-Cookie clearing the refresh_token cookie (revoking every session for the authenticated user); the body itself carries no data.