Token Oversight
Organization owners' inventory of all members' API tokens with metadata, revocation, and OAuth application tokens.
Token Oversight
Overview
Organization Owners get an inventory of all members' API tokens that are bound to the organization, with the ability to revoke any of them — individually or in bulk during offboarding. This answers the security questions that matter: who holds credentials to our organization, with what scope, are they still used, and were they revoked when someone left.
Requires the token.inventory_view and token.revoke capabilities (Owner only — see Roles & Permissions).
Metadata Only — Never Raw Values
The inventory shows token metadata only. Raw token values are never displayed — to anyone, ever, including Owners.
This is deliberate, and it is how every major platform (GitHub, Stripe, Atlassian, Okta, AWS) implements organization token oversight:
- Raw values don't exist to show. UptimeHunt stores only a SHA-256 hash of each API token; the secret is displayed once at creation to its creator and never again.
- Exposing values would be an impersonation capability. An Owner who can read members' tokens can act as those members — destroying audit-trail attribution.
- It would be a compliance finding, not a feature. A SOC2 auditor treats secondary access to credential values as a control deficiency; access reviews are expected to work from metadata (owner, scope, age, last use) plus revocation — which is exactly what this inventory provides.
The Token Inventory
UI: Organization → API Tokens.
API:
curl "https://app.uptimehunt.io/api/v1/orgs/acme/tokens?status=active&stale_days=90" \
-H "Authorization: Bearer {access_token}"Each entry contains:
| Field | Description |
|---|---|
id, name | Token identifier and the name its owner gave it |
prefix | Display hint (uh_xxxxxxxx…) for correlating with configured clients |
owner | The member who created the token (ID + email) |
enabled, status | active / disabled / expired / revoked |
created, expires_at | Lifecycle timestamps |
last_used | Last successful use — updated with up to 15-minute granularity |
revoked_at, revoked_by | Set when revoked; the revoker can differ from the owner |
Filters: owner, status, stale_days (only tokens unused for at least N days). Pagination: limit/offset (default 50, maximum 200). Default sort is last_used ascending — stale tokens first, since those are what an access review hunts for.
Scope: this organization's tokens only
The inventory is scoped by the token's organization binding, not by who its owner is. Tokens a member created for their personal workspace or for other organizations are invisible here and cannot be revoked from here — Owners govern exactly the credentials that can touch their organization's data, nothing more.
Revoking Tokens
Requires token.revoke. Revocation takes effect immediately and is recorded in the audit log as token.revoked with the revoking actor.
Single token:
curl -X DELETE https://app.uptimehunt.io/api/v1/orgs/acme/tokens/17 \
-H "Authorization: Bearer {access_token}"All of a member's organization tokens (offboarding):
curl -X DELETE https://app.uptimehunt.io/api/v1/orgs/acme/members/42/tokens \
-H "Authorization: Bearer {access_token}"The bulk revoke is also invoked automatically when a member is removed from the organization — each revocation audited with reason member_removed. See Members — Offboarding.
Automation blast radius
Revoking a token that drives a Terraform pipeline, Ansible playbook, or the Kubernetes auto-discovery operator breaks that automation at its next run (HTTP 401). Check last_used before revoking — a token in active use is probably wired into something. The structured API errors make the resulting failure diagnosable on the automation side.
OAuth Application Tokens
Tokens granted to OAuth applications (for example MCP connectors for Claude) do not appear in the organization inventory, by design:
- OAuth tokens are user-identity credentials — they authenticate a person, not an organization, and a member may use the same authorized application across several organizations and their personal workspace. There is no per-organization slice to safely inventory or revoke.
- Organization access flows entirely through membership: every request an OAuth-authenticated client makes is authorized against the user's current membership and role. Removing a member therefore severs organization access for every token that user holds — of any kind — within at most 60 seconds (the token-introspection cache window). Offboarding does not depend on finding and revoking each OAuth grant.
- Members review and revoke their own authorized applications in their account's connected-apps settings.
The practical consequence for Owners: govern people via membership and organization credentials via this inventory — OAuth grants take care of themselves when membership changes.