Skip to main content

​
Troubleshooting: ACCOUNT_LOCKED at dashboard sign-in

The dashboard sign-in boundary rejects attempts on a locked account with HTTP 403 and code: ACCOUNT_LOCKED. The rejection is deterministic: every attempt against the lock returns the same refusal until the lock clears, so the fix is to identify which lock you are under and clear it — not to keep submitting the form. This page covers the login lock on dashboard users (email + password). It is unrelated to API keys, which reject with their own codes, and to the WhatsApp Business Account lock Meta applies to your WABA — see the coverage map at the end for those siblings.

​
Symptom

At sign-in, the request returns:
Until the lock clears, every attempt returns the same refusal before the credential check runs — including attempts with the correct password. The lock is on the account, not on a specific credential guess.

​
Cause matrix

Three independent sources apply a login lock. The recovery path differs, so identify yours first:
Only organization owners and administrators can clear a lock on another member. The unlock path is a tenant-owned control — Orbit support cannot unlock accounts on your behalf except through the break-glass route below.

​
Fix steps

Work these in order. Stop at the first one that restores access.
  1. Wait out the lock window (brute-force lockouts). If the lock came from failed attempts, it expires on its own. Make yourself a coffee and sign in once — a single successful sign-in also resets the failed-attempt counter.
  2. Owner/admin unlock. Ask any owner or administrator of your organization to open the members list, find your user, and unlock/unfreeze the account. This clears every lock class, including holds that never expire on their own.
  3. Break-glass via a second owner. If the locked member is your organization’s only owner, a second owner must unlock them. If nobody else holds owner/admin rights — a single-owner org where the owner is locked — open a support ticket with the details listed below; support treats that as a break-glass escalation rather than a routine unlock.

​
Do not retry-loop — the reject is deterministic

Repeatedly submitting the sign-in form does not shorten a brute-force window and does not bypass an admin or suspicious-login hold. Each attempt is refused with the same 403 before any credential check runs, so a retry loop only produces noise in your own audit view. Read the lock, clear it, then sign in once.

​
Password reset path

A password reset does not clear a lock — the reset flow validates your email ownership, but the lock check runs before the credential check, so resetting mid-lock still returns ACCOUNT_LOCKED at the next sign-in. Use reset in exactly one scenario: after the lock is cleared, when you suspect the failures were not yours (a suspicious-login hold, or failed attempts you do not recognize). Then rotate the password before signing back in. If the reset itself refuses your new password with “This password has been seen in known data breaches. Please choose another.” or a security-requirements message, that is a policy rejection on the new password, not a lock on the account: see Troubleshooting: password rejected during password reset. For the full recovery lifecycle: token lifetimes, rate limits, failure modes, and the one-click API-key revocation that follows a successful reset: see Password reset and API-key revocation.

​
What to send support

If you genuinely cannot reach an owner/admin (the break-glass case), open a ticket with:
  • The email address of the locked account.
  • Your tenant ID (Settings → Organization; a teammate’s organizationId from GET /api/v1/me works too).
  • The error code and message exactly as returned, and the request_id from the response’s meta block.
  • For a suspected compromise: the sign-in timestamps you do not recognize, so support can distinguish a hold from an admin freeze.
Never include a password or a session token in the ticket.

​
Coverage map

The ACCOUNT_LOCKED family is deliberately small; do not confuse the login lock with these lookalikes:
  • WhatsApp connection troubleshooting — WHATSAPP_ACCOUNT_LOCKED is Meta’s lock on your WhatsApp Business Account after a sustained policy issue (Meta error 131031). It blocks WhatsApp sends, not dashboard sign-in, and recovery runs through Meta Business Support, not your organization owners.
  • Authentication, key mode, and IP allowlist — covers API-key rejections (INVALID_API_KEY, EXPIRED_TOKEN, WRONG_KEY_MODE, IP_NOT_ALLOWED) plus the SAML/SCIM gates on the login path. A revoked or expired key never reports ACCOUNT_LOCKED.
  • Hot-desking sign-in rejects — the voice-side sign-in: binding an agent to a shared desk phone. Its guards (HOT_DESK_RACE 409, terminal-state 410/404) are session-ledger races, unrelated to the login account lock.
  • Password rejected during password reset — the reset form’s 422 when the submitted password is on a known-breach list or fails the baseline rules. It refuses the password, not the account, and never reports ACCOUNT_LOCKED.

​
See also