The second of six Dashboard Guide pages. Covers Users (list and per-user detail), Team, and API Keys — everything that controls who can log in to your integration and who can manage your dashboard.
The list shows every end user who's authenticated through your integration, scoped to whichever environment the header's environment toggle is set to. The search box filters by email or device hint — not email alone. Three status buttons (All / Active / Disabled) and a separate "Flagged" toggle (risk-flagged users only) combine with the search text; all three filters apply together. Results paginate at 50 per page. When a user has an external_user_id (bridged in via BYOAM or your own identity system), it's shown in small mono text right under their email in the table. The "Method" column only ever shows Passkey, OTP, or Magic Link — that's because it reflects a user's last actual login method, and TOTP/SMS/backup codes are step-up factors attached to an already-authenticated session, never the method of the login itself.
The detail page (click any row) opens to four real stat tiles — Registered, Total Logins, Active Sessions, and Auth Events (90d). That "90d" isn't a display choice: auth_events rows older than 90 days are actually deleted on a rolling basis, so this page can only ever show what still exists. Below that:
Reached from the sidebar as a per-project nav item, but worth being precise about: Team access is company-wide, not project-scoped. The API behind this page filters by your company ID, not the project ID in the URL — the project ID is only used to confirm you have access to some project in that company. Inviting, removing, or changing someone's role here affects their dashboard access across every project your company owns, not just the one you're currently viewing.
The role model is exactly what earlier sessions settled on: binary Owner or Member, nothing in between. An invite always creates a Member — the UI says so directly ("They'll join as a Member. Role changes are managed separately"). Once someone's on the team, an Owner can promote them to Owner or demote them back, or remove them outright — removal revokes all of that person's active sessions immediately. One real guardrail: the last remaining Owner can be neither demoted nor removed — both actions are disabled with an explanatory tooltip if you try. Pending invites show a real Pending/Expired badge (computed from the invite's actual expiry timestamp) and can be resent at any time.
Generating a key is a three-field form: Key Name (required), Environment — a real Test/Live dropdown, defaulting to Test — and Expires (Never / 30 days / 90 days / 1 year, defaulting to Never). The generated key is shown exactly once, in full, with a copy button; the table afterward only ever shows its th_test_…/th_live_… prefix. Each row also shows Created, Expires (or "Never"; turns red once actually past), Last Used (or "Never" if it's never authenticated a request), and Status — Active or Revoked, with the revocation date shown once revoked. Revoking is the only action available per key, is permanent, and takes effect immediately.
One thing worth being precise about: the plan-based limit shown on this page ("Environment limit reached") isn't counting environments in the test/live sense — it's counting your number of currently active (non-revoked) API keys against your plan's allowance (Free: 1, Starter: 3, Growth: 10, Scale: effectively unlimited). Revoking a key frees up a slot the same as never having created it.