Lovable authentication errors: what each one means

How to see the real authentication error

Supabase sends back an error code with every failed auth request, even when the app hides it. There are three places to read it, from quickest to most detailed.

1. The browser console. Open the live app in Chrome, press F12, choose Console, and try to sign in. Generated code often logs the error object here even when the screen shows nothing. Look for AuthApiError followed by the message.
2. The Network tab. If the console is empty, switch to Network, filter on auth/v1, and try again. Sign-in calls token, sign-up calls signup. Click the red row, open Response, and read the error_code and msgfields. This works however the app handles errors, because it's what Supabase actually sent.
3. The auth logs. On your own Supabase project, open the dashboard, then Logs, then Auth. Each request has a line with the error and, for the database errors further down, the reason behind it. This is the only place that shows why a sign-up failed inside the database.

Once you have it, make the app show it to you every time. Supabase puts a stable code on every auth error, and branching on that code is safer than matching the message text, which can change.

const { error } = await supabase.auth.signInWithPassword({ email, password });

if (error) {
  console.error("Sign-in failed:", error.code, error.status, error.message);

  if (error.code === "email_not_confirmed") {
    showMessage("Check your inbox for the confirmation link.");
  } else if (error.code === "invalid_credentials") {
    showMessage("That email and password don't match.");
  } else {
    showMessage(error.message);
  }
}

Lovable authentication error messages and what they mean

The message is what users see. The code is what Supabase's error code list documents. Find your row, then read the section it points to.

The status code helps too. Supabase's notes say a 422 means the request was understood but the user is in a state that blocks it, a 429 means a rate limit, and a 500 means the auth service is degraded, most often because of something in the database.

Invalid login credentials when the password is right

This message covers three different situations on purpose. If Supabase said "no account with that email", anyone could type addresses into your sign-in form and learn who your customers are. So it gives the same answer for all three:

• There's no account. The user signed up with a different address, a typo, or a work email instead of a personal one.
• The account has no password.The user signed up with Google, or with a magic link, and is now trying the email and password form. Their account exists, but there's no password on it to match.
• The password is wrong. Including a password manager filling in the one from the preview address instead of the live one.

To tell which it is, look the user up. On your own Supabase project that's Authentication, then Users, in the dashboard. On Lovable Cloud, Lovable's authentication page says users and auth settings live under More, then Users. Search for the email. No row means no account. A row whose provider is Google means the second case: tell them to use the Google button, or to set a password through the reset flow, which only works once the reset link itself is fixed. A row with an email provider and a recent confirmation means the password really is wrong.

One thing not to do: change the form to tell users whether an email exists. It feels helpful, and it undoes the protection above. Show one message for this code, and put a "forgot password" link right under it.

Email not confirmed, and confirmation emails that never arrive

Supabase's password guide says Confirm email is on by default for hosted projects. A new user is created unconfirmed and isn't signed in until they click the link in their email. Until then, the right password gives email_not_confirmed. That's the setting working. The problem is almost always that the email never arrived.

Supabase's SMTP guide explains why. The built-in mail sender is for development only. It sends 2 messages an hour, and it refuses to deliver to any address that isn't on your project's team, failing with "Email address not authorized". That's why sign-up works for you and your co-founder and fails for every customer: you're on the team, they aren't.

The fix: send auth emails from your own domain

• On Lovable Cloud:Lovable's authentication page says auth emails come from a generic sender by default, and you can send them from your own domain under More, then Emails.
• On your own Supabase project:add custom SMTP (Resend, Postmark, Amazon SES, or similar) under Authentication settings. Supabase's guide says that once it's saved, the project sends to every address, starting at 30 messages an hour, which you can raise on the Rate Limits page.
• For users already stuck:after email works, have the app offer a "resend confirmation" button when it sees email_not_confirmed, using supabase.auth.resend. Or confirm them by hand from the Users list.

The password reset guide walks through the SMTP setup step by step, because the same sender carries reset emails. One more check while you're there: if the confirmation link arrives but opens localhost, the Site URL is wrong, which is the same fix as a reset link that opens localhost.

User already registered, or a sign-up that does nothing

A sign-up with an existing email behaves in one of two ways, and the quiet one confuses everyone. Supabase's sign-up reference says that when Confirm email is on, signing up with an address that already has an account returns what looks like a normal user, with no error, but nothing was created and no email is sent. Only when confirmation is off does it return "User already registered".

So the common report, "the sign-up form says check your email, and no email ever comes", is often a returning user who forgot they had an account. The tell is in the response: the fake user has an empty identitieslist. Supabase's reference says to check for exactly that.

const { data, error } = await supabase.auth.signUp({ email, password });

if (error) {
  showMessage(error.message);
} else if (data.user && data.user.identities?.length === 0) {
  // An account with this email already exists. Nothing was created.
  showMessage("You may already have an account. Try signing in, or reset your password.");
} else {
  showMessage("Check your inbox for the confirmation link.");
}

Word the message as a suggestion rather than a fact, for the same privacy reason as the sign-in form. If you see user_already_exists on a brand-new email, check for a double-clicked sign-up button: the first request created the user and the second one failed. Disable the button while the request runs.

Email rate limit exceeded and other 429 errors

Supabase caps how often auth actions can happen, and every cap returns a 429. The numbers from its rate limits page explain most launch-day failures:

over_email_send_rate_limit is the first row, and custom SMTP from the previous section is the fix: the 2-an-hour cap belongs to the built-in sender. over_request_rate_limitis the third row. Supabase's error list says it counts requests per client IP address, so a launch event where everyone shares the venue's wifi can hit it. You can raise it on the Rate Limits page of your own Supabase project. If it shows up with ordinary traffic, look for code that retries a failed sign-in automatically, which turns one failure into thirty.

Database error saving new user: the signup trigger

This one is not an auth problem. Supabase's troubleshooting page says it comes from something in the database that runs when a user is created: a trigger on the auth.userstable that fails, or a constraint that isn't met. Lovable apps almost always have one such trigger. It copies each new user into a profiles table so the app can store a name and avatar.

The trigger runs inside the same step as the sign-up, so if it fails, the whole sign-up fails and the user gets this 500. It usually breaks after a later prompt changed the profiles table: a column was renamed, a new column was made required with no default, or the table was dropped and recreated. The trigger still writes the old shape, and every new sign-up stops. Existing users keep signing in fine, which is why it can go unnoticed for days.

1. Open the auth logs and find the failed sign-up. Supabase's page says the auth log carries the specific message.
2. If it points at the database, open the Postgres logs for the same minute. You'll see the real error, such as a column that doesn't exist, a null in a required column, or "relation does not exist" for a missing table.
3. Fix the trigger function to match the table as it is now, or restore the table it expects. Supabase's page says to edit the function from the Database Functions page if the reference is wrong.
4. Sign up a fresh test user and check that the profile row appears.

The hang-after-login guide has a version of this trigger written so a missing profile can't block sign-up, and a backfill for users created while it was broken.

Auth session missing and Invalid Refresh Token errors

These show up after sign-in, as users who get logged out at random or pages that suddenly can't load their data. Supabase's sessions guide explains the mechanics. The access token lasts an hour by default, and the app trades a refresh token for a new one. A refresh token can be used only once, with a 10-second grace period. Sessions also end when the user signs out, changes their password, or does another security-sensitive action.

refresh_token_not_found means the browser held on to a session the server no longer has, usually because the user signed out on another device or changed their password. Sending them to the sign-in page is the right response, not an error message. refresh_token_already_usedusually means two copies of the Supabase client refreshed at the same time and one lost: two browser tabs racing outside the grace period, or a second client created in another file, which generated code does more often than you'd think. The fix is one client, created once and imported everywhere.

"Auth session missing" is the client saying it has no session to give. In Lovable apps it's usually code that asks for the user before the saved session has loaded, on the first render after a refresh. Wait for the auth listener's first event before deciding the user is logged out. The two-clients problem and the early-redirect problem both have full fixes in the hang-after-login guide.

Signups not allowed, provider disabled, and other settings

A few errors are settings doing exactly what they were told. Each code in Supabase's list names the switch.

• signup_disabled: new accounts are off. Lovable's page describes a Disable sign-up setting that stops new sign-ups while existing users can still sign in. Someone may have turned it on while testing.
• email_provider_disabled or provider_disabled: the sign-in method isn't enabled. Lovable's settings list each method as Enabled or Disabled, and on Business and Enterprise workspaces an admin can block a method for every project.
• weak_password: the password fails the project's rules. Show the rules next to the field before the user submits, not after.
• email_address_invalid: Supabase rejects example and test domains. If your own testing uses test@example.com, use a real inbox, or an address with a plus sign on your own email.
• captcha_failed: bot protection is on, but the form isn't sending a valid challenge token, often because the CAPTCHA widget was removed in a later edit.

How to ask Lovable to fix an authentication error

Lovable fixes auth errors well when it has the code, and badly when it has "login is broken". Under pressure, the quickest changes a tool can make are to turn off email confirmation, loosen the database rules, or create the user with an admin key from the browser. Each makes the error go away and opens a bigger hole. Paste the code and say what not to touch:

If the fix comes back and the error doesn't change, don't prompt the same thing again. That loop is the pattern in Lovable breaking the same feature on every fix, and the next step is to read the logs yourself or hand it to someone who will.

Test Lovable sign-up and sign-in before launch

Most of these errors only appear with real users, because the builder is always on the team, always confirmed, and always signed in. Run this on the published app, in a private browser window, with an email address that isn't on your Supabase or Lovable team:

1. Sign up with the new address. The confirmation email should arrive within a minute, from your own domain.
2. Click the link. It should open your live domain, not localhost or the preview address.
3. Check that a profile row was created for the new user.
4. Sign out, then sign in with a wrong password. You should see one clear message and a forgot-password link.
5. Sign up again with the same address. The app should suggest signing in, not claim to have sent an email.
6. Sign in with Google using an address that already has a password account, and note what happens, so support knows what to tell users.
7. Leave the tab open for over an hour, then use the app. It should still work, because the session refreshed on its own.
8. Sign in on a second device, change the password there, and go back to the first. It should send you to sign-in, not show an error.

The free vibe-coded app launch checklist covers sign-in alongside data access, secret keys, and backups, if you want the rest of the pre-launch list in one place.

When to get help with Lovable authentication

If the code pointed at a setting and the test above passes, you're done. Get help when the database error keeps coming back after each Lovable edit, when users report being logged out and you can't reproduce it, or when the fix needs the service role key and you aren't sure where it's safe to put it. Sign-in is where an app decides who sees whose data, so a quick fix here can leak more than it repairs. On The Chat Company, an AI-generated demo I took over, I kept about 20% of the code and rewrote the rest before it could serve real businesses. Nine weeks later it was a SaaS used by 30+ businesses.

Sign-up, sign-in, and sessions are one of the six areas I check in a Launch-Ready Review: a fixed-price review of a vibe-coded app for $900–1,500 in three to five days, with a written report and a priced fix list. After that, the care plan keeps logins, payments, and the database watched while you keep building in Lovable, from $400 a month. Or just send me the app's linkand the error code from the Network tab, and I'll tell you which cause it is.