API Key Detail
A named key detail page for last use, scope, rotation window, serving project, and the workload it is allowed to power.
Identity and scope
A key detail page should make the serving project, workload label, and scope model obvious before the operator thinks about rotating or replacing the secret.
That prevents key sprawl from turning into a billing or incident response problem later.
Rotation health
Rotation timing, last successful use, and stale-or-overlapping windows belong on the key detail page itself because that is where the operator decides whether the key is still safe to keep around.
The platform should make those windows visible without requiring the team to inspect raw audit logs first.
Project and playground links
A named key should stay linked to the project it serves and the playground lane that proves it still works. That way issuance, testing, and rotation stay part of one flow instead of separate chores.
It also makes it much easier to explain why a key exists during an audit review.
{
"key_label": "hrs-sandbox-backend",
"project_id": "proj_sandbox_workforce_review",
"scope": "hrs.lookup.identity",
"last_used_at": "2026-03-12T14:18:00Z",
"rotation_due_in_days": 22,
"stale": false
}A key detail page should connect identity, scope, last use, and rotation timing in one operational record.