TL;DR: You cannot send custom verification, password reset, or magic link emails in Lovable Cloud. The auth webhook configuration isn't exposed. Here's what you can actually do about it.
The Hard Truth
Before we go any further, let me save you hours of frustration. Here's what's possible:
| Email Type | Custom Template? | Why |
|---|---|---|
| Verification (signup) | ❌ No | Auth hooks not exposed in Cloud |
| Password Reset | ❌ No | Auth hooks not exposed in Cloud |
| Magic Link | ❌ No | Auth hooks not exposed in Cloud |
| Welcome (post-signup) | ✅ Yes | You trigger it yourself |
| Any other transactional | ✅ Yes | You trigger it yourself |
The frustrating part? The infrastructure to customize all of these exists. Lovable Cloud just doesn't expose the Auth Hooks configuration needed to override the default emails.
So what do you do? You have three real options.
Option A: Live With It
This is what I did. Accept the limitation and work around it.
The strategy is simple: push users toward Google SSO where no emails are needed at all. For the stubborn ones who insist on email/password, they'll get Supabase's default (ugly but functional) emails for verification and password reset. Then, once they're verified and in your app, you hit them with a beautiful custom welcome email that you fully control.
Is this a compromise? Absolutely. Your verification email will look generic. But your welcome email can be on-brand and beautiful. Pick your battles.
I'll show you exactly how to implement both Google SSO and custom welcome emails below.
Option B: Eject from Lovable Cloud
If you need full control over every email, you can connect an external Supabase project instead of using Lovable Cloud.
Create a Supabase account and project at supabase.com
In Lovable, go to Settings → Integrations → Connect External Supabase
In the Supabase Dashboard, navigate to Auth → Hooks → Add a new hook for send_email
Point the hook at your custom email function URL
Now ALL auth emails route through your function with your templates
The trade-offs are real though. You'll have separate Supabase billing, you'll manage the project yourself, and you lose some of Cloud's seamlessness. But you get full control over every email that goes out.
Option C: Build Your Own Verification
The nuclear option: skip the built-in email verification entirely and roll your own.
"I want to build a custom email verification system. Here's what I need:
- Disable the default email confirmation in auth settings
- Create a verification_codes table to store 6-digit codes with expiry timestamps
- When a user signs up, generate a code, store it, and send it via email
- Build a verification page where users enter their code
- When verified, mark email_verified = true in their profile
- Check this flag before letting users access protected features"
This is more work to set up and maintain, and you're now responsible for security edge cases (rate limiting, code expiry, brute force protection). But you get complete control over the experience from start to finish.
Implementing Google SSO
Let's start with the path of least resistance. Google auth sidesteps the email problem entirely - no verification email, no password reset email, just works.
What You Need To Do Manually
These steps happen outside of Lovable - you'll need to configure things in Google's console:
Head to the Google Cloud Console and create a new project (or use an existing one)
Navigate to APIs & Services → Credentials → Create Credentials → OAuth Client ID
Choose "Web application" as the application type
Under "Authorized JavaScript origins", add your Lovable preview URL (something like https://your-project.lovable.app) and your production URL if you have one
Under "Authorized redirect URIs", add the callback URL from Lovable Cloud. You'll find this in Users → Auth Settings → Google Settings
Copy the Client ID and Client Secret, then paste them into Lovable Cloud → Users → Auth Settings → Google
What To Prompt Lovable
Once Google is configured in Cloud settings, ask Lovable to build the frontend:
"Add a Google sign-in button to my auth page. When clicked, it should start the Google OAuth flow and redirect users back to /auth/callback when done. Show an error toast if login fails."
What Lovable builds for you: A Google sign-in button that handles the OAuth redirect flow, plus the callback page to receive users after they authenticate with Google.
That's it. User clicks the button, Google handles the auth flow, they land back in your app authenticated. No emails involved.
Implementing Custom Welcome Emails
Now for the one thing you CAN fully customize: what happens after a user signs up. When someone completes signup (however they did it - Google, email/password, whatever), you can trigger your own beautiful welcome email.
What You Need To Do Manually
Sign up at resend.com - this is your email provider
Verify a domain. This is required - you can't just send from any email address. Go to Domains in Resend and add something like mail.yourdomain.com. You'll need to add some DNS records (DKIM, SPF). Takes 10-30 minutes and requires access to your domain's DNS settings.
Once verified, create an API key at resend.com/api-keys
In Lovable, add this as a secret called RESEND_API_KEY (Cloud → Secrets)
What To Prompt Lovable
Once your Resend API key is saved as a secret:
"Create a backend function called send-welcome-email that sends a welcome email using Resend. It should accept the user's email and optional name. Use my domain hello@mail.yourdomain.com as the sender. Make the email welcoming and on-brand."
What Lovable builds for you: An edge function that connects to Resend using your API key and sends a formatted welcome email.
Triggering the Email (Only Once)
You want the welcome email to send once - the first time someone signs in - not every time they log in.
"When a user signs in for the first time, send them a welcome email using the send-welcome-email function. Add a welcome_email_sent column to the profiles table to track this. Check if it's false before sending, then set it to true after sending. Pass their email and name to the function."
What Lovable builds for you: An auth state listener that:
- Checks if the user has already received a welcome email
- If not, calls your welcome email function
- Marks
welcome_email_sent = trueso they don't get duplicate emails
What's Happening Under the Hood
You don't need to write this yourself, but here's what Lovable creates when you make these requests:
For Google SSO:
- A button component that triggers the OAuth flow
- A callback page that handles the redirect from Google
- Error handling with toast notifications
For Welcome Emails:
- An edge function that runs on Lovable's servers
- Connection to Resend using your API key stored in secrets
- A flag in your profiles table to prevent duplicate sends
- Logic that detects first-time sign-ins and triggers the email
For Custom Verification (Option C):
- A verification_codes table with code, user_id, expiry columns
- An edge function to generate and send verification codes
- A verification page UI with code input
- Logic to validate codes and mark users as verified
The Bottom Line
Lovable Cloud is great for building fast. This is one of its current limitations. Your options are:
- Accept it - Use Google SSO as primary, live with default emails for email/password users, send custom welcome emails
- Work around it - Build your own verification system from scratch
- Eject - Connect an external Supabase project where you have full dashboard access
Pick based on how much the default emails bother you and how much extra work you're willing to take on. For most apps, Option A gets you 90% of the way there with 10% of the effort.