Skip to content

Your account

Both actions live in the dashboard under Account. They take a browser sign-in session: a CLI credential is refused with 403 and code dashboard_session_required; a named access key or an API key is refused earlier with a plain 403 that carries no code. If the dashboard itself answers dashboard_session_required, your session predates credential attribution: sign out and sign in again.

Under Account → Security, choose Change password, enter the current password and the new one. The new password follows the same rules as registration, 12 to 128 characters among them.

What happens on the server, in one transaction:

  • The password changes.
  • Your other browser sessions are signed out. The session you changed it from stays.
  • CLI logins and named access keys stay. Revoke a machine under Account → CLI & Devices if that is what you need.
  • Outstanding password-reset links and pending CLI sign-in requests are voided.
  • Passkeys, authenticator apps and recovery codes are untouched.

A wrong current password answers 400 with a field error, not 401, so the dashboard never signs you out over a typo. Two failure budgets answer 429: ten per hour per account and client address, and twenty per hour per account across all addresses, so spreading the guesses over many addresses does not buy more of them. The deletion request shares both, and every answer the route gives once your session is accepted spends a unit, a rejected new password and a step-up round trip included. If the attempts are not yours, someone else is signed in with one of your sessions. Sign out all sessions, in this same Security section, ends them and asks for no password. A confirmation email follows every change.

If you cannot sign in at all, use Forgot password on the sign-in page instead. That path is broader: it deletes every access key on the account, CLI logins and named keys included. See Access keys and API keys.

Under Account → Danger zone, choose Delete account, confirm with your password and, when the account has a second factor, with a passkey or an authenticator code.

The request is refused with 409 and code account_deletion_blocked while the account still owns something the deletion would orphan. The reasons array says what:

  • apps: the account is the Owner of at least one app. Delete those apps, or finish a cross-workspace transfer so you are no longer the owner.
  • pending_transfer: an outbound cross-workspace transfer is still pending. Cancel it, or wait for the recipient to accept (or for the seven-day invite to expire).
  • subscription: the account’s workspace is on a paid plan, holds a subscription, or has a checkout in progress. Cancel it under Billing first.

Once accepted, the deletion is scheduled for the start (UTC) of the day 30 days after the request, and the account freezes at once:

  • Every browser session is signed out and every CLI login, named access key and API key is revoked. They do not come back if you cancel; create new ones afterwards. A CI pipeline deploying with one of that account’s access keys starts failing with 401 at once, not on the purge day.
  • Until the deletion runs, every call made with the account’s credentials answers 403 except reading the account, cancelling the deletion, signing out and the bearer check GET /v1/authenticated. Signing in still works, so you can cancel.
  • An email names the date.

To cancel, sign in before that date. The dashboard shows the pending deletion and a Cancel deletion button; the API equivalent is DELETE /v1/account/deletion. Cancelling lifts the freeze and nothing else.

On the scheduled day the server deletes the account and, when the account is the sole owner of its workspace, the workspace with it. Security audit rows keep the account id, the client address they were recorded with and the workspace’s Stripe customer id, under the privacy policy’s fraud-prevention and billing carve-outs, with the deleted account’s email address removed from them. Billing records stay with the payment provider. If an app or a paid plan reappeared during the window, the deletion is cancelled instead, the account is active again, and an email says why.

Route What it does
POST /v1/account/password Change the password. Body { "currentPassword", "newPassword" }.
POST /v1/account/deletion Schedule the deletion. Body { "password", "stepUp"? }. Answers { "scheduledFor" } in epoch milliseconds.
DELETE /v1/account/deletion Cancel a scheduled deletion.
GET /v1/account deletionScheduledFor is the scheduled time in epoch milliseconds, or null.

See the API reference for the full request and response shapes.