← All sessionsHomeSearch
C7 EST | 14 Day AI Sprint·Day 13 | Connecting n8n to backend & Collaborate using GitHub + Build Day: Building "Jerry" ·4:55:00

Day 13: Front End Meets Backend — Lovable to n8n by Webhook and .env, the Lovable<->n8n MCP Connector, Respond to Webhook, and GitHub for Teams

Akhil Mentor for the plenary half (his fourth and final session) - webhook/API teaching, two Lovable<->n8n demos, GitHub block; fought audio drops throughout · Uthappa Host - schedule, feedback, workbook briefing (Level 5), breakout logistics

The short version

  1. API vs webhook, settled with a delivery analogy: calling the restaurant every five minutes is an API (active, on demand); the restaurant calling you is a webhook (passive, event-driven). Even a plain Gmail 'send' node 'is an API call... using Gmail API behind the scenes.' Polling for a signup would be '10,000 API calls in a day' - 'a bad design.'
  2. Wiring a vibe-coded front end to n8n: the Webhook node has a TEST URL (you must click listen each time) and a PRODUCTION URL (always on once published). The HTTP method must match on both ends - the front end POSTs, so the node must listen on POST - or the webhook silently never fires. The URL is a secret: put it in a .env file Lovable creates, never in the prompt.
  3. The reverse direction, brand new at recording: Lovable's n8n MCP connector (Settings > Connectors, paste the SERVER URL from n8n Settings > MCP Access) lets Lovable read all your workflows and generate a front end from a workflow NAME. Requirements: the workflow is published AND uses a schedule, webhook, form or chat trigger. 'Lovable can only read. It cannot write' - you add the Respond to Webhook node yourself, after all processing, or the UI never gets an answer.
  4. GitHub as Drive-for-code: repo = folder; fork = your copy, governed by license.md (n8n's allows internal/non-commercial use, hence self-hosting on Hostinger for ~$6-10 a month instead of ~20 a month, minus the hosted product's 'flavors of AI'); branches isolate teammates; a pull request moves a child branch into main after review (Copilot chat can sanity-check the diff); commits are the version history.
  5. Workbook (Level 5): connect a Lovable CHAT INTERFACE to your expense tracker by webhook - chat only, because of the 2-hour window and Lovable's 5 credits/day. The hackathon is Level 6.

The concepts

01

Front end -> n8n: test vs production URL, matching methods, and the .env secret

how-to

The 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.'

Do it in this order
Why it matters

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:

02

Lovable's n8n MCP connector: a front end from a workflow name (read-only)

how-to

You name the workflow. Lovable reads it through MCP and builds the interface. Then it cannot fix the one node you forgot - because it can only read.

Setup: Lovable Settings > Connectors > Connect n8n with the SERVER URL from n8n Settings > MCP Access - the whole instance, not one workflow. Lovable can then search workflows, read details and execute them. Two requirements for a workflow to be visible: it must be published, and it must start with one of four triggers - schedule, webhook, form or chat; otherwise 'no workflow was found' (shown live, fixed by changing the trigger, publishing, toggling MCP access in workflow settings). From a single prompt naming the expense tracker, Lovable generated a chat/dashboard UI and asked style and feature questions (quick input, history, balance, category breakdown, initial balance). Data flowed - salary +1000, lunch -250, balance 750 in the UI, the Executions log and the Sheet - only after adding a Respond to Webhook node after all processing steps; 'Lovable can only read. It cannot write.' Exclusive to Lovable at recording: 'not for Bolt, Emergent... only for Lovable as we speak.'

Do it in this order
Why it matters

The fastest route from any n8n workflow Paul already runs to a client-facing UI - with the two gotchas that stop it working.

Go deeper

In one line: Lovable Connectors -> n8n server URL (MCP Access); workflow must be published with schedule/webhook/form/chat trigger; add Respond to Webhook yourself; connector is read-only.

Connector reads the whole n8n server (search/execute/details) (l3186075 0:54-0:58)

Published + one of four triggers, or 'no workflow was found' (l3186075 1:21-1:26)

Respond to Webhook needed for the UI to get data back (l3186075 1:32-1:34)

Read-only: Lovable will not edit the workflow (l3186075 1:34)

Lovable-exclusive at recording (l3186075 1:00)

▶ Watch this taught:

03

GitHub for teams: repos, forks and licenses, branches, pull requests, commits

GitHub is Google Drive for code. The folder is a repo, the copy is a fork, and the license file tells you what you may do with the copy.

Repo = folder; GitHub = backup and collaboration for code 'whether it's manually written or it's vibe coded.' Fork = your own copy, governed by license.md - n8n's allows use 'only for your own internal business purposes or for noncommercial or personal use', which is why self-hosting a fork on Hostinger (~$6-10/month) beats ~20/month hosted, at the cost of the hosted 'flavors of AI' ('90% of the job done'). Branches: isolated copies so Smith, Donald and Aziz work in parallel without touching main; vibe-coding tools expose 'switch branch.' A pull request (merge request) is 'the process of any change moving from child branch to parent branch' - it shows a line-by-line diff and needs review; GitHub's Copilot chat can be asked whether the change matches the intended scope. Commits are 'version history of each document', per branch; n8n's master had 17,483 commits. Built for the hackathon teams forming the next day.

Why it matters

Paul's Catalyst Session 16 covers GitHub in depth; this is the 30-minute team-collaboration subset.

Go deeper

In one line: Repo=folder, fork=licensed copy, branch=isolated workspace, PR=reviewed merge into main, commit=history entry; self-host forks per the license.

GitHub = Drive-for-code; repo = folder (l3186075 1:47-1:49)

Fork under license.md; n8n's permits internal/non-commercial use -> self-host on Hostinger ~$6-10/mo (l3186075 1:50-1:59)

Branches isolate teammates; switch branch in Lovable/Bolt (l3186075 2:04-2:09)

PR = child -> parent merge with diff and review; Copilot chat to sanity-check (l3186075 2:10-2:15)

Commits = per-branch version history; n8n master 17,483 commits (l3186075 2:17-2:19)

▶ Watch this taught:

Every concept, three clicks deep

The same concepts as a quick reference: the closed row is the glance, open is the study card, and every timestamp jumps into the recording.

01Front end -> n8n: test vs production URL, matching methods, and the .env secretWebhook node = test URL (manual listen) + production URL (live after publish);

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)

02Lovable's n8n MCP connector: a front end from a workflow name (read-only)Lovable Connectors -> n8n server URL (MCP Access);

Lovable Connectors -> n8n server URL (MCP Access); workflow must be published with schedule/webhook/form/chat trigger; add Respond to Webhook yourself; connector is read-only.

Connector reads the whole n8n server (search/execute/details) (l3186075 0:54-0:58)

Published + one of four triggers, or 'no workflow was found' (l3186075 1:21-1:26)

Respond to Webhook needed for the UI to get data back (l3186075 1:32-1:34)

Read-only: Lovable will not edit the workflow (l3186075 1:34)

Lovable-exclusive at recording (l3186075 1:00)

03GitHub for teams: repos, forks and licenses, branches, pull requests, commitsRepo=folder, fork=licensed copy, branch=isolated workspace, PR=reviewed merge into main, commit=history entry;

Repo=folder, fork=licensed copy, branch=isolated workspace, PR=reviewed merge into main, commit=history entry; self-host forks per the license.

GitHub = Drive-for-code; repo = folder (l3186075 1:47-1:49)

Fork under license.md; n8n's permits internal/non-commercial use -> self-host on Hostinger ~$6-10/mo (l3186075 1:50-1:59)

Branches isolate teammates; switch branch in Lovable/Bolt (l3186075 2:04-2:09)

PR = child -> parent merge with diff and review; Copilot chat to sanity-check (l3186075 2:10-2:15)

Commits = per-branch version history; n8n master 17,483 commits (l3186075 2:17-2:19)

Tools referenced

ToolCoverageMomentContext
n8ndemonstratedWebhook trigger, Respond to Webhook, MCP Access, Executions
Lovabledemonstrated.env file, n8n connector, generated expense-tracker UI
GitHubdemonstratedn8n repo, license, branches, PRs, commits
GitHub CopilotdemonstratedPR sanity check in GitHub chat
Google SheetsdemonstratedExpense tracker data verified
GmaildemonstratedOnboarding email; bankrupt alert
HostingermentionedSelf-hosting n8n ~$6-10/month
BoltmentionedNo n8n MCP connector at recording; branch-switch UI shown

Action items

    Resources mentioned

    Resources
    • docDay 13 workbook (Level 5) - chat interface on your expense tracker
    • docNot captured in the recording

    Extraction notes

    This page was built from an auto-generated transcript, which garbles product and people's names. Those were corrected silently in everything above and logged here for transparency. The warnings flag claims that were true on the recording day but change fast.

    Transcript corrections applied

    The transcript saysThe trainer actually means
    an atom / any 10 / and 8 10 / IT andn8n
    white coded / wipe coded / Y podvibe-coded
    Tippathe host (see ais-day00)
    AchillesAkhil
    20 pounds (n8n subscription)~20/month hosted plan; currency garbled

    True on recording day — verify before relying