Webhook vs API, GET vs POST - the hotel and the waiter
Two booking sites sell the same two rooms. The webhook is how the hotel finds out a room just went - instantly, in one direction.
Forty minutes of analogy before any configuration. Webhook: a listener that never stops waiting; when the event happens (a booking, a completed scrape) it fires once, one way - 'as soon as the booking is done, block those rooms' - carrying a notification, not the goods. API: bidirectional - the waiter takes your request to the kitchen and brings a response back; the hotel date-change example needs confirmation, so it is an API. GET retrieves (the breakfast menu); POST submits (a booking) - quizzed repeatedly until the chat gets it.
Both nodes were already seen: the Webhook in Day 6 (Retell's end-of-call push) and the HTTP node in Day 7 (Fireflies). Today formalizes the pair and adds the SOP: native node if one exists; Webhook/HTTP otherwise.
This is the mental model that makes every 'connect X to n8n' question answerable in ten seconds.
Go deeper
In one line: Webhook = passive one-way event notification into your workflow; API = two-way request/response you initiate; GET reads, POST writes; prefer native nodes, fall back to Webhook/HTTP.
Webhook 'always listening', single-direction, event-fired (l3186054 0:24)
API bidirectional: send, process on server, response returns (l3186054 0:43)
GET = retrieve; POST = submit/create (l3186054 1:12)
Seen before: Webhook in the voice session, HTTP in the Jerry/Fireflies session (l3186054 0:01-0:03)
SOP: native node when available; Webhook/HTTP when not (l3186054 1:50)
▶ Watch this taught:







