Skip to main content
This page is about contact syncing and marketing-style email data. It is not the same thing as Supabase auth emails like magic links and confirmation emails.

​
What Email Means In This Repo

This repo uses email providers mainly to keep a contact record of your users. That means when a user signs in, the app can:
  • create that user as a contact
  • update the contact later
  • optionally store extra info like purchase status
This is useful if you want to:
  • build a mailing list
  • sync users into your email tool
  • trigger later email flows outside the app

​
What The Repo Already Does

The email service is already wired into the app. The main files are:
  • lib/email/contacts.ts
  • lib/email/providers/*
The integration is designed to be:
  • non-blocking
  • safe to retry
  • provider-agnostic
So if email sync fails, sign-in should still continue normally.

​
Choose Your Provider

Public provider selection: 
NEXT_PUBLIC_EMAIL_PROVIDER=loops
Optional server-only override: 
EMAIL_PROVIDER=loops
EMAIL_PROVIDER takes priority if both are set. Supported values:
  • loops
  • resend
  • brevo
  • none

​
Which Provider Should You Pick?

​
Loops

Good if you want:
  • a simple default
  • easy contact syncing
  • a path to nicer branded email workflows later
NEXT_PUBLIC_EMAIL_PROVIDER=loops
LOOPS_API_KEY=...

​
Resend

Good if you want:
  • a very developer-friendly product
  • a simple contact API
  • optional segment assignment
NEXT_PUBLIC_EMAIL_PROVIDER=resend
RESEND_API_KEY=...
RESEND_SEGMENT_ID=...
Use RESEND_SEGMENT_ID only if you want contacts automatically added to a segment.

​
Brevo

Good if you want:
  • contact lists
  • CRM-like contact management
  • a custom purchase-state attribute
NEXT_PUBLIC_EMAIL_PROVIDER=brevo
BREVO_API_KEY=...
BREVO_LIST_ID=2
BREVO_PURCHASED_ATTRIBUTE=PURCHASED
Use BREVO_PURCHASED_ATTRIBUTE only if that attribute already exists in Brevo.

​
What Happens When A User Signs In

At a high level:
  1. the user authenticates
  2. the app reads the configured email provider
  3. the app sends the user contact data to that provider
  4. the contact is created or updated
Different providers handle the final API call a little differently, but the app logic stays the same.

​
Contact Sync vs Auth Emails

This is important:
  • contact sync is handled by the email provider integration in this repo
  • auth emails are handled by Supabase Auth email delivery
If you want pretty magic link emails or confirmation emails, that is a separate SMTP/template setup on the Supabase side.

​
How To Set It Up

  1. Pick one provider
  2. Create an account with that provider
  3. Generate the API key
  4. Add the env vars to .env.local
  5. Restart the app
  6. Sign in with a test account
  7. Confirm the contact appears in your provider dashboard

​
Verification Checklist

Your email setup is working if:
  • a test user signs in successfully
  • that user appears in your chosen email provider
  • the app still works even if email sync temporarily fails

​
Common Mistakes

  • setting the wrong provider name
  • forgetting the provider API key
  • using a segment/list/attribute ID that does not exist
  • expecting Supabase magic link emails to be controlled by this service