Backed by: the control-plane seam’s own routes. Scope: keys:rotate for the key list.
What it shows
Registration is what a connection is, checking one is the deeper diagnostic, rotate and revoke is the maintenance, and the credential model is why none of it needs anything from us.
The registration state — which keys are live, their ages, and their validity windows.
The endpoint the connection is registered against, and the base path the seam mounts at.
The environment, which the token is bound to — a staging credential cannot reach production.
Two live keys is normal
Not an exception.
Rotation is append, prove, then expire: both keys are valid between the first step and the third, and the versioned key array is what that state is for.
A failed ping means needs reconnecting
Never a silent dead link.
The address changes — a custom domain, a renamed Worker, a moved environment.
pithy dashboard connect --updateRe-points both the URL and the base path.
The base path is the one thing that cannot be discovered
Everything else is: a declared admin route carries its fully mounted path, so nothing hardcodes a capability’s prefix.
The seam’s own mount point is the exception, because it is the manifest’s address.
Rotating from here
All three calls are made by the management client, because all three are signed and only it holds a private key.
The CLI never writes a rotation into your D1. It asks; the client registers; your Worker accepts or refuses.
Nothing is written anywhere until your Worker has accepted the registration, so there is no state in which your row and the client disagree about which keys exist.
An unreachable Worker fails the rotation and changes nothing on either side.
Revoking
Immediate, unilateral, and requiring nothing from us — see revoking us.
Revocation is checked before any validity window, so it takes effect on the next request.
Your infrastructure stays passive
Storing a new key is one write in a route handler. No Workflow to run, no cron to schedule on your side.