Supabase on your landing pages
Serious lead gen operators end up wanting the raw data in a database they control: to join leads with spend, to run SQL on lead quality, to feed a buyer portal or a rep app. Building the endpoint that receives the leads is the part that usually stalls, because someone has to write it and keep it running.
Supabase removes that part. Every table already has a REST endpoint, and LanderLab's webhook posts each lead to it as a flat set of column names and values. Postgres inserts the row, Row Level Security decides what the request may do, and the lead is in your database with the campaign and the variant on it.
A Postgres row per lead, in your schema
The request body is flat, one key per column, so each lead becomes a row with typed columns, a created_at timestamp from the column's default and an id your other systems can reference. Keys that match no column are rejected, which keeps stray data out of the table.
Because it's Postgres, the row is ready for anything SQL does: a view of leads per campaign per day, a join with your cost table, a unique index on email if you'd rather turn away repeat submits than store them twice.
Locked down with Row Level Security
The webhook writes with your project's publishable key, and Row Level Security decides what that key may do. Allow inserts on the leads table and nothing else, and the key can add leads but never read, change or delete them, so lead data stays out of reach even though the key isn't secret.
The secret key, which bypasses Row Level Security, never has to leave your own backend: a lead form doesn't need it.
Your own source of truth for lead quality
Builders, CRMs and trackers each hold part of the story. A Supabase table with every lead and its utm_campaign, click ID, landing page and variant is the part you control. Load daily spend into a second table and a SQL view gives cost per lead by campaign and variant; add the outcomes your buyers or reps record and it gives cost per sale.
That's the honest way to settle a split test: not which variant got more form fills, but which one's leads turned into money.
Leads that survive a failed insert
Every lead is also kept in LanderLab's Leads tab, filterable by date and variant and exportable as CSV on Grow and up, unless Lead Compliance Delivery is on. If an insert ever fails, say after a column was renamed, the lead isn't gone: fix the table and backfill from the export. Send through LanderLab Workflows (beta) instead and the Runs view shows exactly which lead's request failed.
