Supabase rows read, enriched and written back
Read, insert, update and delete Supabase rows from a workflow: new-row watches, AI enrichment, approvals. Connects with project URL and service key.
- Category
- Data & databases
- Connect
- Paste an API key · managing connections
- Operations
- 4
- Triggers
- none yet
Supabase exposes every project's Postgres tables as a REST API, and the Supabase integration speaks that API directly: read rows with a PostgREST filter, insert one or many, update or delete the rows a filter matches. That makes a table a natural source and sink for workflows: watch it for new rows, enrich them with an AI agent, write the result back, and hand a row the agent is unsure about to a person in Slack. Runs keep the rows each step read or changed, so a bad update traces back to its filter and input. Describe the workflow in plain English and MadMax writes the filters, picks your project connection and runs the read step against your real table during the build so downstream steps are shaped by real rows.
What teams build
- A watch on the
profilestable keyed onidfires per new signup, an AI agent with the browser tool reads the company's website for industry and size, andupdate_rowswrites those columns back before Slack #signups gets a one-liner. - A webhook from your app fires on a new post, an AI classify step sorts it into fine, borderline or remove, and a switch publishes it, sends it to an approval in Slack, or runs
delete_rowsand emails the author the reason. - A Sunday schedule runs
list_rowsonsessionswithexpires_at=lt.<now>and deletes them, then loops over orphaned uploads deleting each row and its storage object with a web request, and emails the counts.
How it connects
Paste your Project URL (https://your-project.supabase.co) and the project's service role secret from Settings, API in the Supabase dashboard. MadMax sends it as both the apikey header and the bearer token, the way PostgREST expects. The service-role key bypasses Row Level Security, so it is stored encrypted, used only server-side at run time and never rendered back into the UI. Filters use PostgREST syntax (status=eq.active, email=ilike.*@acme.com), and update and delete require one, so a workflow can never touch the whole table by accident. See managing connections.
Related
Every Supabase operation MadMax can run
Straight from the integration's manifest, so this list is what the steps on the canvas can actually do today.
| Operation | What it does |
|---|---|
| create row | Insert a row (or rows) into a table. Returns the inserted row(s) because we request `return=representation`. |
| delete rows | Delete rows matching the filter. Requires a filter, because without one PostgREST would delete every row in the table. |
| list rows | Read rows from a table. Use `filter` for PostgREST conditions (`status=eq.active`), `select` to pick columns, `order` to sort. |
| update rows | Update rows matching the filter. Only the columns you supply change. Requires a filter, because without one PostgREST would update every row. |
Works with
Describe the workflow. MadMax builds it and tests it on your data.
Free to start, no card. Connect your apps, say what should happen in plain English, and watch each step run against real data before anything goes live.