What it is
An automatic notification one service sends to another when something happens — "payment received" or "new order" — instead of asking "anything new?" every minute.
How we apply it
The backbone of most of our n8n automations: a marketplace order triggers the chain of actions immediately rather than waiting for someone to start it by hand.
Where a webhook helps a business
- A manager should learn about a deal status change at once, not whenever they next open the CRM.
- A payment went through, and it should be recorded without manual reconciliation.
- A customer wrote to a bot, and the lead should move on immediately: to the CRM, to a spreadsheet, to the person in charge.
- A visitor answered a greeting card or filled in a form, and the owner wants that in their own system.
Webhook or polling
A webhook is an address that another system calls by itself when something happens there. Polling is the reverse: your program asks the API "anything new?" every N seconds.
- A webhook is the choice when the service can send one and you have a public HTTPS address: CRMs, payment systems, Telegram in webhook mode.
- Polling is the choice when there are no webhooks or the server cannot be exposed. That is how Wildberries slot monitoring works: the bot asks the API every 30 seconds.
- Telegram bots support both. Long polling needs neither an open port nor a public address, so most of our bots run that way.
How we use it
- In lead automation the bot, Bitrix24, the payment system and Google Sheets are not connected to each other: each one talks only to n8n. When a deal status changes, Bitrix24 calls the n8n address itself, and the workflow finds the responsible manager and messages them in Telegram. Payment events arrive at the same hub.
- The subscription-sales bot polls Telegram by default, and for a server with a public address it has a webhook mode with a built-in aiohttp web server. A setting switches the mode.
- In the UNLOCK card service the recipient's choice reaches the owner in Telegram, and submissions are also sent out by webhook.
- The service login bot works without a webhook: the service's server is in Russia, where Telegram is unreachable, so the bot lives abroad, polls Telegram itself and fetches the service's event queue every 20 seconds.
We build webhook-driven chains under Automation.
Common problems
- Repeated delivery. An event may arrive twice, and processing must survive that: a payment is not counted again, a lead is not duplicated.
- A public HTTPS address is required. A server behind NAT or without a certificate cannot receive a webhook. Then it is a tunnel or polling.
- You cannot see whether the event arrived. In n8n every run sits in the execution log, so a lead can be checked without reading code. Without a log, finding a lost event is guesswork.
- Secrets in the address. A webhook URL is effectively a password: whoever knows it can send events. Keys and tokens stay in n8n, not in the workflow file.
When you do not need it
If the event is rare and a reaction five minutes later bothers nobody, scheduled polling is simpler. And if a service cannot send webhooks, there is no need to invent them: polling every 30 seconds, as in slot monitoring, does the job reliably.