Front end -> n8n: test vs production URL, matching methods, and the .env secret
how-toThe form submitted, n8n did nothing, and nothing was wrong - except the front end was POSTing to a node listening for GET.
A webhook node listens on a URL 'just like tuning a radio to a frequency.' It offers two: a Test URL that only works while you click 'listen for test event', and a Production URL that is always on once the workflow is published (Lovable can even read the production URL from the workflow's metadata). The demo: a mock registration page in Lovable sends name/email to the n8n webhook; first attempt failed on GET vs POST - 'when my front end is posting data, don't you think my n8n should also listen on the post method' - then n8n sent an onboarding email. Secrets: the webhook URL is a secret ('if someone gets access to this URL, they will send any random information'), so ask Lovable to create a .env file, add WEBHOOK_URL=..., and never paste keys, tokens, passwords or URLs into the prompt - 'even Lovable or Bolt cannot read the contents of this file.'
Every Paul Lovable/Supabase site that talks to an automation goes through exactly this handshake; the two failure modes here are the two he will meet.
Go deeper
In one line: Webhook node = test URL (manual listen) + production URL (live after publish); match HTTP methods both ends; keep the URL in .env, not in prompts.
Two URLs: test (listen per test) vs production (always on after publish) (l3186075 0:27, 0:40)
HTTP method must match sender and receiver or nothing fires (l3186075 0:41-0:47, 1:29)
Webhook URL is a secret -> .env file via Lovable; never in the prompt (l3186075 0:37-0:39)
Use API for on-demand generation; webhook for unpredictable events like signups (l3186075 0:23-0:26)
Every n8n node action is an API call under the hood (l3186075 0:13)
▶ Watch this taught:




