Built-in Duplicate Email Handling with Customizable Email Templates

[Yembot31013]

Problem Statement

Currently, when users try to register with an existing email, Supabase returns a "successful" response with fake user data. I know this is for security reasons and it is valid, but since in our code we expected the user to confirm their account, we show a component that tells the user that registration was successful and they should check their email to confirm and log in, even if this is for security reasons, but it still creates several issues:

1. Poor User Experience: Users think registration succeeded but receive no confirmation email
2. Security Risk: Frontend can't distinguish between real and fake user responses
3. Database Constraints: Attempting to use fake user IDs causes foreign key violations
4. Confusion: Users don't know why they can't access their "new" account

Current Supabase Behavior

// User registers with existing email
const { data, error } = await supabase.auth.signUp({
  email: '[email protected]', // Email already exists
  password: 'password123'
})

// Supabase returns:
// - error: null (no error)
// - data.user: { id: "fake-uuid", email: "existing@email.com" }
// - But this user doesn't actually exist in auth.users
// - No email is sent
// - User thinks registration succeeded

well we could easily fix the Security Risk and Database Constraints, by checking if the user exists in the database, but numbers 1 and 4 couldn't be fixed by us except if we wanted to compromise security by telling the user the truth about what is going on. So in short, the problem is user experience; we need to balance user experience and security together.

Proposed Solution

Since we can't know if the account exists immediately until we look it up, which could also have some technical and performance costs, Supabase should send an "Account Already Exists" Email. Automatically send an email to the existing user if enabled by the developer on the dashboard. The default email body should be telling the user that the account with that email already exists, including clear action buttons to Sign In or Forgot Password, while also adding a security note about ignoring if not requested by them.

And also make us developers able to customise the Email Templates via the Dashboard, and also add additional template variables for dynamic content and we can access the extra optional data passed along the signup and also do conditions in the email templating.

Benefits

For Users

• ✅ Immediate Feedback: Know registration didn't work
• ✅ Clear Guidance: Get helpful email with next steps
• ✅ No Confusion: Understand why they can't access the account.
• ✅ Quick Recovery: Direct links to sign in or reset password

For Business

• ✅ Better UX: Users don't get confused by "successful" registration
• ✅ Higher Conversion: Users can quickly recover and sign in
• ✅ Reduced Support: Fewer "I registered but can't sign in" tickets
• ✅ Professional Image: Helpful, guided user experience

Vote with 👍 if you'd like to see this feature implemented!

This would balance both the security of user enumeration attacks and user experience.

[ChangHyun2]

Q how did you resolve this issue in current version?

---

I checked duplicated email with empty properties

user_metadata, role, identities

registered email

{
  user: {
    id: '1ccd4d06-2420-4cf6-a739-3fefa8cba301',
    aud: 'authenticated',
    role: '',
    email: '[email protected]',
    phone: '',
    confirmation_sent_at: '2025-09-06T15:43:25.827746738Z',
    app_metadata: { provider: 'email', providers: [Array] },
    user_metadata: {},
    identities: [],
    created_at: '2025-09-06T15:43:25.827746738Z',
    updated_at: '2025-09-06T15:43:25.827746738Z',
    is_anonymous: false
  },
  session: null
}

unregistered email

{
  user: {
    id: '2bfbe262-4251-451f-b759-d045eb1f718e',
    aud: 'authenticated',
    role: 'authenticated',
    email: '[email protected]',
    phone: '',
    confirmation_sent_at: '2025-09-06T15:42:03.78065215Z',
    app_metadata: { provider: 'email', providers: [Array] },
    user_metadata: {
      email: '[email protected]',
      email_verified: false,
      phone_verified: false,
      sub: '2bfbe262-4251-451f-b759-d045eb1f718e'
    },
    identities: [ [Object] ],
    created_at: '2025-09-06T15:40:40.529473Z',
    updated_at: '2025-09-06T15:42:04.913535Z',
    is_anonymous: false
  },
  session: null
}

[Yembot31013]

What I did was use the user.id from the returned user object and email provided by the user to make a request to my server, checking if the user exists with my service key. Since the current user making the request isn’t authenticated yet, I had to rely on the service key.

To protect the endpoint from potential security abuse (e.g., hackers probing to discover existing accounts), the endpoint always returns a generic success response. This way, exploiters can’t distinguish between valid and invalid accounts.

Inside the endpoint, the real logic happens: I pass in the email and user ID.

• If the ID check fails, it means Supabase returned a fake user for an existing email account.
• In that case, I trigger the Resend API to email the user, letting them know the account already exists. The email suggests signing in or resetting their password if they’ve lost access and also clarifies they can ignore the message if they didn’t try to sign up.

I hope this helps @ChangHyun2 but I mean the Supabase team could make this smoother and cleaner if they handle this from their side.