01
Authorise with OAuth
Sign in to Supabase, authorise your organisation and pick a project. The scopes are shown up front, and the connection stays pending until you choose.
Supabase + Fromly
Email your Supabase users the moment they sign up
Connect your Supabase project once. Every user in Supabase Auth becomes a contact, new signups arrive within seconds, and your welcome email sends itself.
Start freeYour first 1,000 emails free. No credit card.
A user signs up
- Signed upada@lovelace.dev
- Signed upgrace@hopper.dev
The contact appears in seconds
Ada Lovelace
ada@lovelace.dev
Just signed upSupabase
The welcome email goes out
Acme · hello@acme.com
Welcome aboard, Ada
Finish your setupWhat the Supabase integration does
Fromly connects to your Supabase project over OAuth: you authorise your organisation, pick a project, and the sync starts. There is no SDK to install, no code to deploy and no CSV to export. Your users show up as contacts on their own.
Every user in Supabase Auth becomes a contact with their email, name, signup date and last sign-in. Two paths keep the list current: a database trigger posts each new signup to Fromly in real time, and an hourly sync imports everyone on the first run, then picks up anything that changed since, including any signup the real-time path missed.
New signups fire a signed-up event you can build automations on: a welcome email, a multi-step onboarding sequence, a nudge when someone goes quiet. Your existing users are imported without firing anything, so connecting never blasts your whole base.
Fromly reads Supabase Auth only. It never reads your application tables: your products, your customers’ data, anything you built stays yours alone.
How it connects
From zero to synced contacts in a few clicks, with every permission shown before you grant it.
02
One trigger, one schema
Fromly installs a single trigger on auth.users, inside its own separate schema. It posts each new signup in real time, and it is the only thing database write access is used for.
03
Import, then stay fresh
The first sync imports your existing users. After that, an hourly pass picks up anyone created or updated since, and repairs any signup the real-time path missed.
04
Automate on signup
Each new signup fires a signed-up event for your automations. Existing users are imported without events, so connecting never emails your current base.
What data syncs
Fromly reads Supabase Auth users: email, name and dates. It never reads your application tables.
Contact fields
| Name | What it holds |
|---|---|
| The address the contact is keyed on: one contact per email, never duplicated. | |
| name | Taken from the user’s metadata when your app stores one. |
| signed_up_at | The real date the user signed up in your product, not the import date. |
| last_seen_at | The user’s last sign-in, for spotting who has gone quiet. |
| external_id | The Supabase user id, so the contact stays matched across syncs. |
Events
| Name | What it holds |
|---|---|
| user.signed_up | Fired for users who sign up after you connect: the trigger for welcome and onboarding automations. |
What you can build
Automation
A welcome email that actually arrives on time
The signup lands in Fromly within seconds, the automation fires, and the welcome email is in the inbox while your product is still open in the next tab.
Automation
Multi-step onboarding
A sequence that starts on signup and spaces itself out over the first days. Each step is written once and sent to every new user.
Segments
Re-engage users who went quiet
Last sign-in syncs with every contact, so the users who stopped coming back are one filter away from a re-engagement campaign.
Broadcasts
Announce to your real user base
No exported CSV going stale: a broadcast reaches the users you actually have, as of this hour.
AI agents
Let your agent do the work
Claude, ChatGPT or Cursor connect over MCP and write for your real users, who they are and when they signed up, straight from Supabase.
Access, scoped to the minimum
Reads Supabase Auth only
Fromly reads auth.users: email, name, dates. Your application tables are never read, whatever is in them.
One write, in its own schema
Database write access installs a single trigger in a separate schema, so new signups reach Fromly in real time. It is used for nothing else.
Connecting fires nothing
Existing users are imported without events, so no automation runs against your base the day you connect.
Disconnecting cleans up
The trigger and the schema are removed, the token is revoked and the sync stops. Contacts already imported stay yours.
FAQ
Supabase questions, answered
Does Fromly read my application tables?
No. Fromly reads Supabase Auth users only: email, name, signup date and last sign-in. Your own tables, and anything your app stores in them, are never read.
Will connecting email my existing users?
No. Existing users are imported as contacts without firing any event, so no automation runs against them. Only users who sign up after you connect fire the signed-up event.
What exactly does Fromly write to my database?
One trigger on auth.users, installed inside a separate schema that Fromly owns. It posts each new signup to Fromly in real time, and it is the only thing write access is used for. Disconnecting removes it.
How fast do new signups appear?
Within seconds. The trigger posts each signup as it happens, so a welcome automation sends while the signup is still fresh.
What if the real-time sync misses a signup?
An hourly sync re-imports everyone created or updated since the last pass, so a missed webhook is repaired within the hour and nobody is lost.
What happens when I disconnect?
Fromly removes its trigger and schema from your database, revokes its token and stops syncing. The contacts already imported are kept; they are yours.
Turn your signups into customers with email
Connect Supabase and Stripe, let your agent draft your first flow, and send your first 1,000 emails for free.