If the other system can notify you, use a webhook: it arrives at once and wastes no requests. If it cannot, or if you cannot risk missing a notice, poll. The most robust setup combines the two. It is the question behind “how do I know the customer paid”, “how do I receive the messages” or “how do I know the order changed”.
The two ideas
With polling, your system asks every so often, “anything new?”. You are the one asking, at the pace you choose. With a webhook, it is the other system that calls you: when something happens, it makes an HTTPS request to an address of yours and hands over the data. It does the notifying, at the moment of the event.
Side by side
| Criterion |
Polling |
Webhook |
| Speed |
Delayed until the next interval. |
Almost immediate. |
| Waste |
Many requests that answer “nothing new”. |
A request only when something happens. |
| What you need on your side |
A scheduled task. No public address needed. |
A public HTTPS address that is always answering. |
| If your server is down |
Catches what it missed on the next poll. |
May lose the notice. Services usually retry, but only for a limited time. |
| Security |
You control the connection you make. |
You must confirm the notice really came from who it says. |
| Simplicity |
Very simple. |
A little more care. |
When to use each
| 2 |
Use polling when the other side has no webhooks, when you only want an hourly report, or when you have no public address to receive on. It is what a scheduled task does. See cron jobs.
|
|
| 3 |
Combine them when missing a notice is costly: the webhook handles the immediate side and a slow poll, say hourly, picks up what escaped.
|
|
What a well-made webhook does
| 1 |
Answers quickly with a success code, and only then does the heavy work.
|
|
| 3 |
Copes with the same notice twice: services may resend, and you must not record the same payment twice.
|
|
| 4 |
Logs what it receives, so you know what happened when something fails.
|
|
|
In n8n, the test webhook and the production webhook are different addresses. The test one only answers while it is listening in the editor. The production one only answers with the workflow active. Putting the test address into an outside service is the most common cause of “the webhook does not fire”.
|
|
So that notices are not lost, store them before processing. A notice that arrives and fails halfway can be picked up again if it was stored; if not, it is gone.
|
|
Connecting two systems and not sure which route to use? Tell us what they need to say to each other.
Open a support ticket
|
RECOMMENDED PRODUCT Web hosting with cPanel Domain and SSL included, daily backups and the panel you already know. from $6.60/mo (3-year plan, with coupon) See plans |