Trigger Automations From Any Web App With n8n + Supabase

Something happens in your app, Supabase tells n8n, and n8n runs the workflow — all on the server, so it keeps working when every browser is closed. Your AI assistant picks one of two ways for Supabase to tell n8n:

Two ways Supabase can tell n8n

Direct webhook

Supabase sends the saved row to n8n. For simple events where nothing in the row is private.

Filtered event

A small trusted step sends only the fields n8n needs. For private data, specific changes or extra checks.

Describe Your Automation

Define Your Automation

Describe what happens in your app and what n8n should do next, and let AI turn it into a clear automation summary before anything is built.

I want this existing web app to trigger an n8n workflow automatically when something happens in it — on the server, even when nobody has the app open. The app uses Supabase. The idea: something happens in the app, Supabase tells n8n, and n8n runs the workflow. What should trigger the automation: {{TRIGGER}} When it should run: {{CONDITION}} What n8n should do after that: {{ACTIONS}} The apps or services n8n should connect to: {{SERVICES}} The information the automation needs: {{DATA}} Do not change any files, and do not change the database. This task only defines the automation. Look through the project only enough to use its real names — the actual tables, statuses and features, such as leads or bookings — so the summary describes this app rather than a generic example. Do not audit the code or the database yet. That is the next step. Turn my answers into a short summary with exactly these parts: 1. Trigger event: what happens in the app, in one sentence 2. Source data: the table and the change that most likely represent the event — a new row, an updated column or a deleted row. This is a first guess — the next step confirms it. 3. Conditions: when the automation should run, and when it must NOT run — for example only when a booking's status changes to confirmed, not on every edit 4. Data to send: the smallest list of fields the actions need, and any fields that must never leave the app, such as passwords, tokens or private notes 5. n8n actions: what n8n does, in order, and which service each action uses 6. Duplicate check: the ID that identifies one event, such as the lead ID or booking ID, so the same event never runs the actions twice 7. Expected result: what I should see after one successful run 8. Likely path: a direct Database Webhook, if nothing in the row is private and a simple insert, update or delete marks the event — or a filtered event, if the data must be reduced, checked or transformed first. This is a first guess — the next step confirms it. Rules: - The automation must be triggered by Supabase or trusted server code — never by browser code. - Never ask me for passwords, API keys or other credentials. n8n keeps its own connections to other services, and I set those up inside n8n. - Keep it as small as the automation allows. A new lead that posts to Slack does not need an event-processing system. - If my answers conflict or leave a gap — especially the conditions or the data to send — ask me instead of guessing. Finish with the summary as a compact list I can copy and keep. Then wait for my approval. Do not implement anything.

What should trigger the automation?

A visitor submits the contact form and a new lead is saved.

Should it run every time?

What should n8n do after that?

Add the lead to a Google Sheet, then post a message in our #sales Slack channel.

Which apps or services should n8n connect to?

Google Sheets and Slack

Which information does the automation need?

The lead's name, email and message, and when it was sent.

Never enter passwords or API keys in this card — n8n keeps its own connections to your other services. Adjust the summary with the AI until it matches what you want, and keep this conversation open: every later prompt builds on it. If you ever start a new conversation, paste the summary in first.

Approve the Automation Summary

You should now know what starts the automation, what n8n does, and exactly what it receives.

The summary names the exact app event that starts the automation

It says when the automation should run — and when it must not

It lists what n8n should do, in order

It lists only the information n8n needs

I saved a copy of the final summary

Inspect Your Project

Nothing changes in this step. The AI finds the real event in your app and picks the simplest safe way to send it to n8n.

Check the Web App

Let AI find the table and change behind your event, the data it holds and your security rules, then choose a direct webhook or a filtered event before anything changes.

Using the automation summary we just approved, inspect this project before anything is built. Do not change any files or the database in this task. If the approved summary is not in this conversation, STOP and ask me to paste it. Find and report: - How Supabase is set up: the client, the environment variables, and whether the project keeps database changes in migration files - The tables and columns involved in the event, and how the app marks those records today — statuses, dates, flags - How the event happens today: which screen or action causes it, and whether it inserts, updates or deletes a database row - Which columns identify the event — the row's ID and any status that changes - Which fields n8n actually needs, and every column in the row that is private or unnecessary to send - The existing Row Level Security policies on those tables - Any webhook or automation logic that already exists: Database Webhooks, triggers, pg_net calls, Edge Functions, server routes, or browser code that calls an outside URL - Whether an Edge Function or other server code already handles this action - The secret and environment variable NAMES involved — never their values - Whether an n8n URL, a webhook secret or any Supabase secret key appears anywhere in browser code Do NOT assume the SQL in this repository matches what is live in Supabase. Triggers, webhooks and policies are often changed directly in the Supabase Dashboard. Give me ONE read-only SQL query to run in the Supabase SQL Editor. For the relevant tables only, it should report: - Their columns and types, and whether Row Level Security is enabled - Each policy's name, command, roles, USING and WITH CHECK expressions - Existing triggers and the functions they call — including Database Webhooks, which appear as triggers calling supabase_functions.http_request - Whether the pg_net extension is enabled - The names of existing Vault secrets, never their values, if Vault is in use The query must read metadata only. Do not select or print any user rows, secret values or trigger arguments — an existing webhook's arguments can hold its secret. Do not modify anything. If a part cannot run yet, leave it out and tell me, rather than letting the query fail. I will run the query and paste the result back into this conversation. Then give me a short plan: 1. What represents the event: the table, and the exact insert, update or delete — including the old and new values for a status change 2. Where to trigger the automation: from the database change itself, or from an existing trusted server step 3. What to send to n8n: the exact field list, the event ID, and every field that stays out 4. Is a direct Database Webhook appropriate? A Database Webhook sends the WHOLE row — every column — on every matching insert, update or delete. Say yes only if the whole row is fine to share with n8n and a simple insert, update or delete marks the event. 5. Is a filtered event safer? A filtered event sends only the fields above, and only when the meaningful change happens — through a small database trigger function, or through an Edge Function or existing server code when the event needs checks, app logic or extra data. 6. Recommended path — exactly one: direct Database Webhook, or filtered event (and which kind) — and why 7. Implementation plan: the smallest set of changes, in order Rules for the plan: - Use the simplest safe path. Do not add an Edge Function when a Database Webhook or a small trigger function can do the job — and do not send a whole row with private columns just because a Database Webhook makes it easy. - For an update, plan for the automation to run only on the meaningful change, such as a status changing to confirmed — never on every edit of the row. - Trigger from the database or trusted server code. Never from browser code, and never put the n8n URL or a secret in the frontend. - If the event does not change any database row, say so, and recommend the smallest trusted server-side way to send it. - Reuse what the app already has, and keep existing security rules working. Do not loosen any of them. Wait for my approval before changing anything.

Run the read-only SQL it gives you in the Supabase SQL Editor, then paste the result back into the same conversation.

Approve the Plan

Approve the plan once it names the real event and sends n8n only what it needs.

The plan names the table and the exact change that means the event happened

It picks one path — a direct Database Webhook or a filtered event — and says why

It lists exactly which fields go to n8n, and which stay private

Nothing in the plan triggers the automation from browser code

Plan the Workflow

The AI turns your summary into the smallest workflow: a Webhook trigger, one condition if needed, and your actions.

Plan the n8n Workflow

Get a node-by-node plan for a protected Webhook trigger, your condition and your actions, plus sample payloads and test commands.

Now plan the n8n workflow for the approved automation. I will build it in n8n myself. Do not change the project in this task. If the approved summary or the plan is not in this conversation, STOP and ask me for them. Check the current n8n documentation for node names and settings, and tell me where they differ between n8n versions. Do not rely on memory for labels that may have changed. Design the smallest workflow that does the job: - Start with a Webhook trigger node: HTTP Method POST, a path that is hard to guess, Authentication set to Header Auth, and Respond set to Immediately, so Supabase is never kept waiting - For Header Auth, suggest a header name such as x-automation-secret. I will create the secret value myself and never paste it into this conversation. - If the automation should run only in certain cases, add ONE condition — a Filter node, or the Webhook node's own run condition if my n8n version has one. Write it against the real payload: - Direct Database Webhook: n8n receives the row under body — body.type, body.record and body.old_record. For a status change, compare body.old_record.status with body.record.status, so edits to other columns do not pass. - Filtered event: n8n receives only the planned fields, under body. - Then add the actions from the summary, in order, and nothing else. For each one, say which payload field goes into which setting. - Where running the actions twice would cause a visible duplicate — a second Slack message, email or calendar event — add a duplicate check on the event ID, for example n8n's Remove Duplicates node set to remove items processed in previous executions. If an action is naturally safe to repeat, such as an update-or-create matched on the ID, say so and skip the check. Give me: 1. The workflow as a numbered node list, with each node's settings 2. Two sample payloads with fake data, in exactly the shape Supabase will send: one that should run the actions, and one the condition should skip 3. A test command for each sample that I can run in my own terminal. It sends the sample to the n8n Test URL with the auth header, using the placeholders <TEST_URL> and <SECRET>, which I replace myself. 4. What I should see in n8n when the test works Never ask me for passwords, API keys or credentials. I connect each service inside n8n with its own credential system.

Expected result

You have a numbered node list, two sample payloads and a test command for each.

Add the Webhook Trigger

Your n8n must be reachable on the internet — n8n Cloud or a hosted n8n server. An n8n running only on your own computer cannot receive events from Supabase.

Create a new workflow in n8n and add a Webhook trigger Set HTTP Method to POST and enter the path from the plan Set Authentication to Header Auth and create a new credential with the header name from the plan and a long random value Set Respond to Immediately

For the random value, use your password manager's generator, or run this in a terminal:

openssl rand -hex 32

Keep the secret out of your app

Anyone with this value can start your workflow. Keep it in a password manager and paste it only into n8n and Supabase — never into frontend code, the repository or the AI conversation.

Add the Condition and Actions

Add the condition from the plan, if your automation has one Add each action in order, with the settings from the plan Connect each service when n8n asks — sign in or add its key inside n8n only Add the duplicate check where the plan includes one

Expected result

The workflow shows the Webhook trigger, then your condition and actions, connected in order.

Test With Sample Data

Prove the workflow does the right thing before the real app event depends on it.

Your actions really run

A test sends real messages and creates real records in the services you connected. Use the fake sample data, and point actions at a test sheet, channel or calendar where you can, so no customer receives anything.

Open the Webhook node and select Listen for test event Run the first test command with your Test URL and secret filled in Check what each node received and did Send the sample that should be skipped, and check that it stops at the condition

Expected result

The first sample runs every action with fake data, and the second one stops at the condition.

Publish the Workflow

The Production URL only works once the workflow is published.

Select Publish at the top of the workflow Open the Webhook node and switch to the Production URL Copy the Production URL and keep it with your secret for the next step

On older n8n versions, switch the workflow to Active instead. After any later change in n8n, publish again — the Production URL always runs the published version.

Expected result

The workflow is published, and you have its Production URL — the one containing /webhook/.

Connect the Event

The AI builds the smallest safe connection for your path, without ever seeing your secret.

Connect Supabase to n8n

Send the real app event to your published workflow — as a direct Database Webhook or a filtered event — with the secret kept server-side and only the planned fields.

Now connect the real app event to the n8n workflow, following the approved plan and its recommended path. The n8n workflow is published and has passed a test with sample data. If the approved summary or the plan is not in this conversation, STOP and ask me for them. Never ask me for the webhook secret or the n8n Production URL — use placeholders, and I enter both myself. Every request to n8n must: - Go to the n8n PRODUCTION URL — the one containing /webhook/ — never the Test URL containing /webhook-test/ - Carry the auth header the n8n Webhook node checks, with the secret kept on the server side only - Include the event ID, so n8n can spot a repeat - Be sent by Supabase or trusted server code after the change is saved — never by browser code If the path is a direct Database Webhook: - I create it in the Supabase Dashboard. Give me every setting to enter: a clear name, such as lead-created-to-n8n; the table; only the events the automation needs — insert, update or delete; the HTTP Request type; method POST; a timeout; and the header name. - A Database Webhook fires on EVERY matching event on that table. For an update, make sure the n8n condition compares the old and new values, so only the meaningful change runs the actions. - A Database Webhook stores its headers inside its database trigger. Never save the secret into a migration file or the repository. If this project must keep the webhook in migration files, use the filtered path instead, so the secret stays in Supabase Vault. If the path is a filtered event through a database trigger function: - Create one trigger function and one trigger with clear names, such as notify_n8n_booking_confirmed - Fire only on the meaningful change, with a WHEN condition on the trigger — for example old.status is distinct from new.status and new.status = 'confirmed' - Build a small JSON payload with only the planned fields and the event ID — never the whole row - Send it with net.http_post from pg_net, which sends after the change is saved and never blocks it - Read the n8n Production URL and the secret from Supabase Vault (vault.decrypted_secrets) each time. Never write either value into the function, a migration file or the repository. - Catch any error inside the function and raise only a warning, so a problem sending to n8n can never block or undo the app's own change - Make it security definer with a fixed, empty search_path, and make sure nobody using the app can call it If the path is a filtered event through an Edge Function or existing server code: - Send from the trusted server step that already handles the action — or create one Edge Function with a clear name, such as send-lead-to-n8n, run by the database change (for example a Database Webhook of the Supabase Edge Functions type) or by the server code that performs the action - Read the n8n Production URL and the secret from server-side secrets — for an Edge Function, its Supabase secrets. Never from a frontend environment variable. - Verify who is calling the function before doing anything, following Supabase's current recommended pattern - Send only the planned fields and the event ID, with a short timeout - If sending to n8n fails, log it without secrets or personal data, and do not fail the user's action — unless the automation is genuinely required for that action Give me: 1. Which path you used, and what you built or changed 2. For a direct Database Webhook: the settings to enter, one per line 3. Any SQL to run in the Supabase SQL Editor, in ONE block written so it is safe to run again. Put the Production URL and the secret in clearly marked placeholders that I replace in the SQL Editor myself. 4. What I should see in n8n after I perform the event once If this project keeps database changes in migration files, also save the SQL as a new migration, with no secret values in it — Vault secrets are created once, by hand. Deploy the Edge Function if the path uses one, and run the project's build afterwards.

Read which path the AI used and what it built Let the AI finish any code changes, the deploy and the build

Expected result

The AI has given you the webhook settings or the SQL that turns the connection on.

Turn On the Connection in Supabase

Do only the part for your path.

Type the secret only into Supabase

Enter the secret and the Production URL straight into the webhook form, the SQL Editor placeholders or the Edge Function secrets. Never paste the secret into the AI conversation, frontend code, a migration file or the repository.

Direct Database Webhook

Enable webhooks if Supabase asks, then create a new webhook with each setting the AI listed. Type the Production URL and the header value yourself.

Integrations Database Webhooks

Filtered event

Paste the SQL into a new query, replace the placeholders with your Production URL and secret, and run it once.

SQL Editor

If your path uses an Edge Function, add the Production URL and the secret here instead, under the names the AI gave you:

Edge Functions Secrets

Expected result

The webhook appears in the Database Webhooks list, or the SQL and secrets are saved without errors.

Trigger It Once From Your App

The first real event, from the app itself.

Perform the event once in your app, using test details Open the workflow's Executions in n8n Open the newest execution and check the data it received

Expected result

Performing the event in your app started one real n8n workflow execution.

Prevent Duplicates and Handle Failures

What separates a real automation from a demo: repeated events, and a workflow that fails.

Make the Automation Reliable

Make sure repeated updates, double submissions and reruns never duplicate a result, and that a failed workflow never breaks the app.

Now review and harden the automation for what happens outside a perfect demo. Inspect what we built first, and change only what is missing. If the approved plan is not in this conversation, STOP and ask me for it. Duplicates — make sure none of these creates an unwanted second result: - The same row updated again: the condition, or the trigger's WHEN clause, runs the actions only on the meaningful change — not when unrelated columns change, and not when the same status is saved again - A double submission in the app: if one real action can create two rows, fix it at the source — for example with a unique constraint, or by disabling the button while it saves — but only if it really happens - A repeated delivery or a rerun: a retry setting on an n8n node, a manual rerun, or the same event sent twice. Every payload carries the event ID, and actions that would visibly repeat — messages, emails, calendar events, new records — are protected by a duplicate check on that ID. - Do not over-engineer: an action that is naturally safe to repeat, such as an update-or-create matched on the ID, needs no extra check Failures — the automation is secondary to the app: - If n8n is down, slow or returns an error, the app's own action still succeeds and its data stays correct. A lead is still saved when the Slack message fails. - Only if the automation is genuinely required for the user's action — tell me if you think it is — may its failure affect that action - Nothing retries in a tight loop, and nothing in this chain can corrupt or roll back the original record - Enough survives to understand a failure, without secrets or personal data: Supabase keeps each webhook response for a few hours in net._http_response, and n8n keeps each execution. Tell me how to see both. - If a missed automation would really matter — for example a booking that must reach the calendar — add the smallest way to spot it and send it again safely, such as a sent-at column or a small log of events, relying on the duplicate check. For something like a Slack notice, the logs are enough. - Tell me whether to set an error workflow in n8n, so I am alerted when a run fails Keep it the smallest reliable version. Do not build a queue, a retry platform or a monitoring dashboard unless the checks above show the automation needs one. Give me: 1. What was already handled, and what you changed 2. Any n8n changes, node by node 3. Any SQL to run in the Supabase SQL Editor, in ONE block written so it is safe to run again If this project keeps database changes in migration files, also save the same SQL as a new migration. Deploy the Edge Function again if you changed it, and run the project's build afterwards.

Expected result

The AI confirms each case is handled, and any fix is run, saved and deployed.

Lock Down the Webhook

Only Supabase may start your workflow, with only the data it needs, on the production endpoint.

Check the Webhook Security

Check the webhook rejects unknown callers, the secret never reaches the browser, the payload holds only needed fields, and production uses the right URL.

Now make sure the webhook is protected, sends only what it must, and points at production. Check and, where needed, fix: - Authentication: the n8n Webhook node's Authentication is not None. A request with no auth header, or a wrong secret, is rejected and starts no execution. - Where the secret lives: only in n8n's credential and, on the Supabase side, in the Database Webhook's header, Supabase Vault or Edge Function secrets. Search the frontend code, the repository, migration files and logs — it must appear in none of them. - The browser: search the frontend source and the built files for the n8n URL and the secret. Neither may appear, and no frontend environment variable — such as one starting with VITE_ or NEXT_PUBLIC_ — may hold them. The browser never needs to know n8n exists. - The payload: list every field Supabase sends to n8n, and remove anything the automation does not use. If a direct Database Webhook sends private columns, tell me, and switch to a filtered event. - The endpoint: every request goes to the Production URL containing /webhook/ — never the Test URL containing /webhook-test/, and never a temporary tunnel URL - Service credentials: every connection to another app lives in n8n's credential system — never as plain text inside a node, and never in the web app - If I self-host n8n, tell me how to run n8n's security audit, which lists webhooks that have no authentication Give me: 1. Each check, and whether it passed or what you fixed 2. Anything I need to change myself in n8n or in the Supabase Dashboard 3. Any SQL to run in the Supabase SQL Editor, in ONE block written so it is safe to run again

Expected result

Every check passes: only Supabase can start your workflow, it receives only the fields it needs, and the browser never sees the secret.

Test From Your App

Every test starts with a real action in your app — not a click inside n8n.

Test the Complete Automation

Test from the real app event: one execution per event, the right payload, skipped updates, no duplicates, a rejected wrong secret and a safe failure.

Help me prove the automation works end to end, starting from the real app. Clicking Execute workflow inside n8n does not count — every test starts with a real action in the app. If the approved summary and the final path are not in this conversation, STOP and ask me for them. Use test data only: fake names and emails, and a test sheet, channel or calendar wherever the actions allow. Do not send anything to real customers. Walk me through these tests, and tell me what to check for each: 1. App action: I perform the real event in the app 2. Database: Supabase shows the expected new or changed row 3. One execution: exactly one new n8n execution starts for that event 4. Payload: n8n received the expected fields, and nothing else 5. Condition: an event that should be skipped runs no actions 6. External result: the action in the other service completed correctly 7. Unrelated update: changing an unrelated column of the same row does not run the automation 8. Duplicates: repeating the action, or resending the same event, does not create an unwanted second result 9. Wrong secret: a request to the Production URL with no auth header, or a wrong one, is rejected. Give me one command for this, with a placeholder for the URL only. 10. Browser: the n8n URL and the secret appear nowhere in the browser — not in the page source, the loaded files or the network requests 11. Private fields: no unnecessary private field appears in the payload 12. Failure: with the n8n workflow temporarily unpublished, the app action still succeeds and its data is correct. Tell me exactly how to publish it again afterwards. 13. Production: the requests went to the Production URL, not the Test URL 14. Existing features: the app's existing features around this event still work For a failed test, show me where to look: the workflow's executions in n8n, the webhook responses in Supabase, and the function's logs if the path uses an Edge Function. Afterwards, tell me how to remove the test rows and test results. Report expected versus actual for every test, then finish with exactly one verdict: AUTOMATION READY or NEEDS ATTENTION If NEEDS ATTENTION, list only what is still failing.

Continue when the AI reports AUTOMATION READY and the workflow is published again. If it reports NEEDS ATTENTION, fix the listed issues and run the test again.

Know Where to Look

When a run goes wrong, check both sides.

In n8n, every run is listed with the data each node received and any error:

Your workflow Executions

In Supabase, run this read-only query in the SQL Editor to see the latest webhook responses:

Recent webhook responses

select id, status_code, timed_out, error_msg, created from net._http_response order by created desc limit 20;

A status_code of 200 means n8n accepted the event. Supabase keeps these responses for a few hours only, so check soon after a run. If your path uses an Edge Function, check its logs too.

I can see each real event as one execution in n8n

I know where to check when a run fails

Your web app now triggers the n8n workflow automatically whenever the selected event happens.