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.







