CRM & Sales

Connect Instantly and Supabase

Your outbound data stays in a database you own, while Instantly handles the mailboxes and sending.

Scope this integration Book a discovery call

Connects: Instantly and Supabase
Data flows: 4 automated, two-way where safe
Built with: Instantly, Supabase, Claude
Timeline: Live in 3 to 5 business days from scope
Owned by: You, with accounts, credentials and code in your name.

In short

Connecting Instantly to Supabase keeps contacts, sequences and replies in a Postgres database you own, while Instantly handles mailboxes and sending. SBD built IntellReach for a client, a multi-tenant outbound platform on Supabase with Instantly in the stack, where Claude writes each email and interested replies are routed to a person.

The workflows

What runs between Instantly and Supabase.

Each line is one automated workflow. It shows the event in one tool, the checks and mapping in between, the action in the other tool and who is notified.

Multi-tenant outbound platforms
When
A contact list is uploaded
Automation
- Verify and validate
- Map and normalise
- Upsert by key
Then
Verify and enrich it, remove suppressed contacts and store it in Supabase
And
- Audit log entry
- Alert if it fails or goes quiet
- Review queue if unsure
One suppression list everywhere
When
A campaign starts
Automation
- Verify and validate
- Map and normalise
- Upsert by key
Then
Push approved contacts and personalised copy to Instantly
And
- Audit log entry
- Alert if it fails or goes quiet
- Review queue if unsure
Reply classification with AI
When
A reply or bounce webhook arrives
Automation
- Verify and validate
- Map and normalise
- Upsert by key
Then
Record it safely, stop the sequence and classify the reply
And
- Audit log entry
- Alert if it fails or goes quiet
- Review queue if unsure
Interested replies routed to sales
When
A prospect is interested or opts out
Automation
- Verify and validate
- Map and normalise
- Upsert by key
Then
Route them to a person, or add them to the suppression list for every campaign
And
- Audit log entry
- Alert if it fails or goes quiet
- Review queue if unsure

Every record passes through the same stages

1Receive
Webhook or polling from the source tool, with a signed payload and a replay log.
2Validate
We check required fields, types and the record key. Anything that fails goes to the review queue.
3Map
Fields are mapped to the destination schema, with dropdown values, currencies and dates normalised.
4Upsert
Each write is matched on the record key, so a retry updates the existing record.
5Confirm
The outcome is logged, an alert fires if the count stops moving, and a reconciliation runs each night.

Read this first

Where the simple setup breaks down.

A one-step Zap connects Instantly and Supabase in an afternoon. This is what tends to go wrong once volume grows and edge cases appear.

Two systems can disagree on who may be emailed
If opt-outs live only in Instantly, a new campaign or another tool can still contact that person. The suppression list needs one home, checked before any contact is pushed.
Replies arrive out of order
Webhooks can be delayed or sent again, and a contact might reply to step one after step two has gone. Handlers need to be safe to repeat, and to stop the sequence as soon as any reply is recorded.
A multi-tenant mistake is serious
If the platform serves several clients, one missing rule can show or email the wrong client's contacts. Row level security has to apply to every table, including anything written by a webhook.
Bad lists harm the domain
Pushing unverified addresses raises bounce rates, and that damage can outlast the campaign. Verification belongs before the sync, with a stop when bounces rise.

What we wire up

The data flows.

01
When
A contact list is uploaded

Then
Verify and enrich it, remove suppressed contacts and store it in Supabase
02
When
A campaign starts

Then
Push approved contacts and personalised copy to Instantly
03
When
A reply or bounce webhook arrives

Then
Record it safely, stop the sequence and classify the reply
04
When
A prospect is interested or opts out

Then
Route them to a person, or add them to the suppression list for every campaign

Used for

Multi-tenant outbound platforms
One suppression list everywhere
Reply classification with AI
Interested replies routed to sales
Instantly webhooks into Supabase
Row level security for client data
Verified lists before sending
Bounce rate alerts
Personalised copy from a knowledge base
Campaign reporting in your own database

Built with

Instantly
Supabase
Claude
Next.js
Vercel

In every build

What every integration build includes.

Under the hood

Upserts keyed on the record
Each write is matched on the source ID, so a retry or a re-fired event updates the existing record.
Retries with backoff
Rate limits and timeouts are retried with increasing delays. If they still fail, they are parked for review.
Idempotent, loop-safe writes
Two-way flows carry a marker so a change written by the sync does not re-trigger the sync.
Reconciliation
A nightly job compares counts and totals on both sides and lists any record that differs.
Audit log
Each run records the input, the mapping result, the action taken and what triggered it. You can search it by record.
Error monitoring
Failed runs raise an alert. An outcome count also alerts when it stops moving, which catches failures that throw no error.
Review queue
Records the sync is not sure about land in a screen a person can read, correct and release.
Scoped credentials
Each connection has its own credential, limited to the objects it needs and stored encrypted in your account.

For the team

Slack or email notifications
Alerts go to a named person on your team, by Slack, email or WhatsApp.
A runbook
One document per integration: what it does, what each alert means, and what to do in the first ten minutes.
Training
A live session with the people who will use the review queue, recorded for whoever joins later.
Handover
Admin access, billing and code sit in accounts in your name from the start, so the build keeps running if we stop working together.
Sixty days of hypercare
The engineers who built it stay on call after go-live, fix what breaks and tune what the team asks for.
A monthly report
One page in plain language covering runs, records synced, exceptions handled and what changed.

Security and your data

Where the data goes, and who holds the keys.

Accounts: Every platform account is created in your name. We work through managed access you can revoke.
Credentials: Stored encrypted in the orchestration layer, scoped per connection and rotated at handover.
Data in transit: All traffic uses TLS, and webhooks are checked by signature before anything is processed.
Data at rest: We store only what the sync needs and keep no copies of your customer data on our machines.
AI steps: Where an integration uses a model, it is through a business API that does not train on your data.
Retention: Run logs are kept 90 days by default, which you can change. Card and ID numbers are redacted from payloads.
Agreements: DPA and NDA on request. Regional rules covered in our privacy policy.

Keys and sensitive data

How API keys, tokens and personal data are handled.

Keys are kept in a vault
API keys and tokens are stored in the orchestration layer's encrypted credential store or the platform's secret manager. None are written into workflows, repos, spreadsheets or chat.
One credential per connection
Each integration gets its own key, scoped to the objects and actions it needs. A lead sync cannot read invoices. Revoking one key stops one thing.
Service accounts for connections
Connections use a dedicated service user in your account, so nothing breaks when a person leaves and nothing runs under someone's name.
Two-factor on every account
Each platform account we set up has two-factor authentication on, and the recovery codes are handed to you.
Rotation on handover and on request
Keys are rotated when the build is handed over, when anyone with access leaves, and at any time you ask.
Secrets are redacted from logs
Audit logs redact tokens, card numbers, government IDs and anything you flag as sensitive before a line is written.
Webhooks verified before processing
Inbound calls are checked against the sending tool's signature. Unsigned or stale payloads are dropped and counted.
Access you can see and revoke
Our access is through managed roles in your accounts. You can see it, limit it or remove it without touching the build.

Engineering decisions

Decisions we make before writing the first workflow.

Rate limits and backoff
Each API has a ceiling, so calls are batched, queued and retried with increasing delays during busy periods.
Backfill and pagination
The first run loads history as well as new events. Backfills page through the source in order and resume after an interruption without writing a record twice.
Out-of-order and duplicate events
Webhooks can arrive twice or out of sequence. Each event carries a version or timestamp, so an older version cannot overwrite a newer one.
Schema changes
A renamed field or a new dropdown value is a common cause of silent failure. Payloads are checked against a contract, and a mismatch stops the run and raises a flag.
Time zones, currencies, units
Dates are stored in UTC and shown in local time. Amounts carry their currency and quantities their unit, and conversions happen once, in the map step.
Sandbox first
Builds run against sandbox or test accounts with seeded data first. Going live means switching credentials.
Versioned and reversible
Workflows and code are version-controlled. A release can be rolled back in minutes without losing the records processed since.
API deprecations watched
Tools retire API versions on a schedule. We track the dates for every connection in the runbook and upgrade before the cut-off.
Cost per run known
Each run logs its cost, including any model calls, so you can see spend as it builds up.
Run metrics
We chart runs per hour, records in and out, exception rate and latency, which often shows a problem before an alert fires.

Proof

Where we have done this.

Customer story
AI outbound sales platform

A multi-tenant AI outbound platform built for a client, on Supabase and Next.js, with Claude writing emails and Instantly in the stack.
Read the story

The offer

Hire SBD to connect Instantly and Supabase.

We agree a fixed scope in a discovery call and go live in three to five business days. The accounts are in your name, and the engineers who built it stay on call for sixty days after.

Hire SBD for this integration See similar integrations

ScopeOne call to agree the flows, the fields and the owner, written up the same day.
Build4 workflows, the data map above, validation, upserts, retries and reconciliation.
Go-liveWe test in a sandbox first, then switch over. Day three to five from scope for most pairs; longer only if a tool needs approval, such as WhatsApp templates.
HandoverRunbook, training session, alerts to a named owner, admin access and code in your accounts.
AfterSixty days of hypercare, then a care plan or run it yourself.

Questions

What people ask about this pair.

Why not keep everything in Instantly?

For one team on a simple setup, that can be fine. A database makes sense when you need your own reporting, several clients, or data shared with other tools.

Who owns the mailboxes and domains?

You do, and they stay in your accounts. We keep sending domains apart from your main domain to protect it.

Is cold email legal?

It depends on where recipients are and how you found them. We build in opt-outs and suppression, and you should confirm the rules for each market.

Keep exploring

Related to this page

Instantly and Supabase