Your app's data lives in Supabase; the orders, forms and messages that should reach it arrive elsewhere. Bizomate inserts, updates and finds rows in your tables, calls your database functions, stores files and makes signed links to them, and starts a workflow the moment a row is added, changed or deleted, or on a check every few minutes. Every run leaves a record of what it wrote.
| Label | Value |
|---|---|
| Plans | Every plan |
| Connect | Project URL and API key |
| Starts runs | Instantly, from a Supabase database webhook — or every 5 minutes (15 on Free) |
| Kind | Connected app · Database |
Nothing to set up in Supabase: choose the table and a column that only grows, such as the id or created_at. Rows already in the table never start a run.
Bizomate shows a webhook address and a secret to paste into a Supabase database webhook once; a delivery without the secret is refused. The run gets the row's columns, which kind of change it was and, for a change or a deletion, the row as it was.
Matched on the primary key, or on a column with a unique constraint chosen under Match on.
An hour unless you change it, up to seven days.
The anon or publishable key where you can: Bizomate then sees and changes only what your row-level security policies allow. Use the service-role or secret key only when a workflow needs every row.
Row added, changed or deleted starts a run within seconds, and needs a database webhook set up once in Supabase. New row needs nothing in Supabase and checks the table every 5 minutes on paid plans, every 15 on Free; it sees new rows only, not changes or deletions.
The lists in the steps come from what the key can see. With the anon key, a table your policies hide is not listed.
No. Each workflow's trigger has its own address and secret, so two workflows on the same table's changes need two webhooks in Supabase, one each.
Each new row, posted to Slack and added to a sheet.
