Skip to content

Sessions, activity and the account

A person signed in with Omxus can see where they are signed in, sign out of a device, read what happened to their account, take a copy of everything held about them, and delete it. Your site can offer all of that with a few calls. It never sees what the person does on other sites.

Every call below needs the site session from a sign-in (Authorization: Bearer …) and your standard-door client_id. Without a session the answer is 401 signed_out.

Sessions

GET /accounts/sessions lists the live sign-ins:

{ "sessions": [
  { "id": "…", "client_id": "your-site", "kind": "site", "auth_method": "passkey",
    "created_at": 1761800000, "last_used_at": 1761810000,
    "ip": "…", "user_agent": "…", "current": true },
  { "id": null, "client_id": null, "site": "another site", "count": 3 }
] }
  • Your site sees its own sessions in full. Sign-ins on other sites collapse into one last row, "site": "another site" with a count, so the person knows they exist and you learn nothing about where.
  • current: true marks the session that made the call.
  • Times are Unix seconds.

POST /accounts/sessions/revoke signs out, with one of:

Body Signs out
{ "id": "<session id>" } that one session (only if it belongs to this account)
{ "others": true } every session but this one
{ "all": true } every session, this one included

Anything else is 400 invalid_request. The answer is { "ok": true, "revoked": <n> }. POST /accounts/logout ends just the current session.

Activity

GET /accounts/activity returns up to 200 events from the last 90 days, newest first. Older events are deleted.

{ "events": [ { "event": "signout", "at": 1761810000, "ip": "…",
  "client_id": "your-site", "detail": null } ] }

Each event records the site the person was on. Yours carry your client_id; another site's come back with client_id: null, so you see that something happened, never where. The ip is stored truncated.

Re-auth

Export and delete are serious, so they ask the person to prove it is them. Either the sign-in happened in the last 10 minutes, or the request body carries one of:

{ "reauth": { "password": "<prehashed password>" } }
{ "reauth": { "code": "123456" } }

password is the browser prehash, as at sign-in. A code goes to the account's contact address first. Answers: 401 reauth_required (ask them), 401 reauth_failed (wrong; repeated failures lock for a while, as at sign-in).

Export

GET or POST /accounts/export (POST to send reauth) returns everything held about the account: its id on your site, contacts, usernames, passkeys, every session (with expiry and why it was revoked), activity, and vouches. No password hashes, no tokens. The export goes to the person themselves, so nothing is masked.

Delete

POST /accounts/delete (re-auth as above) removes the account: contacts, usernames, profiles, uploaded pictures, passkeys, every session and token, and its activity. The answer is { "ok": true }. There is no undo.

Only the Omxus Account site

Four calls answer only to the Omxus Account site (account.omxus.com), the one client an operator marks account_home. Any other client gets 403 not_account_home. They exist so the person can see every site at once, and so no ordinary site can:

Call What
GET /accounts/connections every site with a live sign-in or grant, newest use first
POST /accounts/connections/revoke { "site": "<client_id>" } sign out of that site and end its grant
GET /accounts/usernames the shared username and each site's own
GET /accounts/checkup the security checkup: password, passkeys, contact, sessions, sites, failed sign-ins in 30 days

To send someone there from your site, link to https://account.omxus.com.

Checked against server/accounts/accounts-routes.js (sessions, activity, re-auth, export, delete, connections, checkup) and accounts-store.js, 30 Oct 2026.