Cannot log in#

A person cannot sign in — on the web panels (/admin, /super-admin, /agency) or in the Android app. This page separates the four really different causes: wrong details, a lockout, a login method that is not enabled, and an account or workspace that is blocked. Find the message in "What you see" first — it names the cause.

Who this is for: the person locked out, and the admin helping them.

Problem#

Sign-in is rejected, or the app bounces back to the login screen. The same account may work on one surface and fail on another (web works, phone does not — or the reverse).

What you see#

Likely causes#

• Simple typos, or using an email when the account is registered under a phone number (or the reverse).
• Five failed attempts — lockout, 15 minutes, applies to web and mobile.
• The person is a contact/lead in the CRM, not a user with a login account.
• On mobile: wrong server address (the field must end with /), or the login method is not enabled for the workspace.
• The account or workspace is suspended, or the workspace is in its deletion countdown.
• The device token expired (90 days) or the user logged out elsewhere.

Quick fix#

1. Wait 15 minutes if there was a lockout, then retry with the exact email or the 10-digit phone registered on the profile.
2. On mobile, check the Server: line at the bottom of the login screen and the Email/Phone and Password/OTP switches — see Login & workspace selection.
3. Try the other login method: password or OTP (if the workspace enabled both).

Step-by-step fix#

1. Confirm the account exists — web Team members (tenant) or Super Admin → Users: the person must have a user account, not just a contact record. A contact record cannot sign in.
2. Check which identifier the account uses — email, phone, or both. Phone sign-in matches the last 10 digits; entering the number with spaces or +91 still resolves, but a number that is not on the profile cannot.
3. Check for a lockout — 5 failed attempts within the window locks that email/phone (and the source IP) for 15 minutes. The lock is timed; it clears itself. Do not keep retrying — every retry during a lockout keeps the door shut.
4. Check the workspace state — if the person is redirected to /admin/subscription-required, the workspace is suspended; if to /admin/privacy, the workspace is in its deletion countdown (owner-only access). Both are billing states, handled on Payments failing.
5. Only then reset the password — an admin resets it from Team members; ask the person to set a new one and sign in once, carefully.
6. Mobile still failing after web works — the server address is the first suspect (must end with /), the login method the second (see Email or OTP not received), the device token the third (sign out and sign in again to get a fresh 90-day token).

Admin fix#

• Unlock early? The lockout clears itself after 15 minutes. There is no one-click unlock — it is a timed counter. If your policy needs different numbers, change them at Admin → Security settings (/admin/security-settings-page): max_login_attempts (default 5) and lockout_duration (default 15 minutes). Changing these affects both web and the mobile API.
• Verify the person's details before resetting anything: correct role, active user, correct phone/email.
• Password reset from Team members — then have the person sign in once immediately to confirm, rather than assuming.
• If the whole team is locked out, suspect something upstream (email/OTP not arriving, a suspended workspace) rather than a mass typo — see Email or OTP not received.

Developer fix#

• Lockouts are counted in the cache with an atomic counter and recorded in login_attempts (LoginAttempt::recordFailureAndMaybeLock). Cache keys: login_lockout:e:{email} and login_lockout:ip:{ip}, bucketed per 15 minutes (intdiv(time(), 900)).
• Clearing the app cache unlocks early — only do this deliberately, and note it, because it also wipes other counters.
• The panel login path is App\Filament\Auth\Pages\Login; the mobile login endpoint applies the same 5-fails/15-minutes rule server-side, so a "web-only" lockout story is usually wrong.
• Mobile auth middleware is DeviceAuthenticate, resolving bearer tokens against device_tokens.token_hash; a 401 UNAUTHORIZED means missing/revoked/expired token — re-login is the fix, not a server change.
• Device tokens are valid up to TOKEN_TTL_DAYS = 90 and are revoked on logout or expiry — not on password change.

Logs to check#

• login_attempts table — who failed, from which IP, when (retained 30 days by default).
• storage/logs/laravel.log — auth-related errors around the attempt time.
• Mobile: the API response code (ACCOUNT_SUSPENDED, NO_WORKSPACE, WORKSPACE_INACTIVE, RATE_LIMITED) is the fastest tell.

When to escalate#

• Lockouts keep returning for a user with a confirmed-correct password — that is a security signal (someone else is guessing), escalate to the super admin.
• Everyone in a workspace is locked out at once.
• A NO_WORKSPACE on an account that should have one — the tenant/user relationship needs a data fix by a developer.

Related guides#

• Email or OTP not received
• Mobile not syncing / push not arriving
• Login & workspace selection
• How mobile login finds your workspace