Summary
Disable an inbox’s sign-in at a provider, and re-enable it later, with one call. Accounts now carry a status, and accounts can be listed and read under pods and inboxes so an agent can audit sign-ins at exactly the scope its key holds.
What’s new?
New endpoints:
PATCH /v0/accounts/{account_id}/update- Update one account. Send{ "status": "disabled" }to refuse every new sign-in for that inbox at that provider, or{ "status": "enabled" }to re-enable it. Requires the newaccount_updatepermission.GET /v0/pods/{pod_id}/accountsandGET /v0/pods/{pod_id}/accounts/{account_id}- List and read the accounts held by inboxes in one pod.GET /v0/inboxes/{inbox_id}/accountsandGET /v0/inboxes/{inbox_id}/accounts/{account_id}- List and read the accounts held by one inbox.
New features:
- Account status: a disabled account carries
status: "disabled"anddisabled_aton every read. An account withoutstatuscan sign in. - Idempotent updates: disabling an already disabled account keeps its original
disabled_at, and enabling an enabled account is a no-op, so a retry never conflicts. account_updatepermission: a separate grant for the write. Unrestricted keys hold it; restricted keys get it only when granted. Reading accounts still needs onlyinbox_read.- Scoped views: the pod and inbox forms return the same account object as
GET /v0/accounts, narrowed to the pod or inbox in the path. An account outside that scope is a 404.
Use cases
Build agents that:
- Cut off a provider that is misbehaving, without deleting the sign-in record
- Pause one inbox’s access to a provider during an incident and restore it afterward
- Audit, per pod or per inbox, which providers each agent has signed in to
- Give a tenant’s key visibility into its own accounts and nothing beyond its pod
See Update Account in the API reference for the request and response shapes.
