Skip to main content
Export your referral intelligence to a table in your own Supabase (or any Postgres) database. After each enrichment job, Clustr sends the opportunities that changed to the table, and every night it reloads the whole table so deletions and CRM or tag changes land too. It’s a data export, not an OAuth app: you connect with a Postgres connection string, and Clustr only ever writes to the one table it manages.
Connecting Supabase is admin-only, under Integrations → Supabase in the dashboard.

​
Connect Supabase

Have your Supabase Postgres connection string ready, then run the three-step wizard.
1

Paste your connection string

In Supabase, go to Settings → Database → Connection string and copy the URI:
Paste it into Clustr and click Continue. Both the direct connection (5432) and the pooler (6543) work.
The string includes your password — Clustr stores it encrypted and uses it only to write the export table. The host must be a Supabase host (db.<ref>.supabase.co or *.pooler.supabase.com).
2

Choose a destination schema

Use existing (pick a schema Clustr found) or Create new (defaults to clustr; names must be lowercase letters, digits, and underscores, starting with a letter or underscore). Click Continue.
3

Confirm the table and sync

Clustr checks <schema>.clustr_referral_paths and either creates it, reuses it, or — on a column shape mismatch — asks you to pick another schema or drop the table. Click Connect & sync to save the connection and run the first full export.
After the initial sync, Clustr pushes the opportunities that changed since the last sync when an enrichment job finishes. If a sync is already running, Clustr does not start a second one: it runs one more pass when the current one ends. Every night (about 02:00 UTC) Clustr also does a full sync. It loads a fresh copy of the table and swaps it in at once, so opportunities deleted in Clustr disappear and CRM or tag changes that did not touch the opportunity are picked up. If your table has row-level security, triggers, views or foreign keys that depend on it, Clustr cannot swap it, and instead writes into the table and removes the rows it did not touch. Large workspaces are read in pages of 5,000 rows. A sync that is interrupted, by a restart or a dropped connection, carries on from the last page it wrote and does not start over.

​
How It Works

Clustr writes a single table, <schema>.clustr_referral_paths — one flat, denormalized row per opportunity. Rows are upserted on id (INSERT … ON CONFLICT (id) DO UPDATE), so re-syncing never duplicates, and the nightly full sync also removes opportunities that no longer exist in Clustr. Because it’s keyed and idempotent, the table is safe to query live, build views on, or point a BI dashboard at.

​
Settings

The Supabase panel shows connection status and sync controls.

​
Table Schema

clustr_referral_paths is keyed on id (used for upserts); all other fields are stored as text so the export never fails on type coercion. Full column reference:

​
Accounts and Connectors tables (optional)

Besides the warm intros, Clustr can export your Accounts and Connectors ledgers. Both are off by default. Turn them on in the connect form’s last step, or later under Integrations → Supabase → Settings. Turning one on starts a sync straight away. They are written into the same schema as the warm intros, by the same sync, with the same rules: every row is upserted on its key, and rows that left the ledger are removed after a complete sync. Turning a table off stops writing it; the table and its rows stay. All columns are text, like the warm-intros table.

​
Competitor monitoring tables (optional)

With competitor monitoring, Clustr can also export your competitors’ activity and the accounts they work. One switch writes both tables: Competitor monitoring, in the connect form’s last step or under Integrations → Supabase → Settings. It is off by default, and turning it on starts a sync straight away. Both tables are written by every sync, including the one that follows each competitor scan, and each sync writes them whole: an interaction you ignore or a competitor you remove leaves them at the next sync. Turning the switch off stops writing them; the tables and their rows stay.
  • clustr_competitor_activity has one row per like or comment, as the Activity tab lists them. activity_id stays the same for the same interaction from one sync to the next. direction is outbound when their person engaged someone’s post, inbound when someone engaged their person’s post.
  • clustr_competitor_accounts has one row per account a competitor ever touched, and per company that buys from a competitor you watch (customer_only is true for those, with no interactions). standing is customer, crm or new, as the Account column reads.
  • has_open_deal, deal_stage and deal_name are the open deal in your CRM, the one the Accounts page shows.
  • Join either table to clustr_accounts on company_id, account_linkedin_id or clustr_account_id.

​
Renaming a table

Every table Clustr writes carries a marker in its comment (clustr:referral_paths, clustr:accounts, clustr:connectors, clustr:competitor_activity, clustr:competitor_accounts). If you rename a table in your database, Clustr finds it by that marker and keeps writing to it under its new name. Clustr only writes the comment when the table has none, so a comment of your own is never overwritten; keep the marker text in it if you edit it.

​
Troubleshooting