The short version: push versus check
Every automation starts with a trigger: the event that kicks it off. There are two ways for an automation platform to learn that something happened. With polling, the platform asks the other app on a schedule, for example every 15 minutes, whether there is anything new. With a webhook, the other app sends the data to a web address the moment the event happens.
Make describes webhooks as a way to send data to Make over HTTPS, creating a URL that an external app, service or another scenario can call to trigger a scenario. [1] Webhooks usually act as instant triggers, and the scenario runs immediately after the URL receives a request. [1] Polling triggers, which Make says often have names starting with Watch, check for new data since the last run on the scenario's schedule. [2] Instant triggers carry an instant tag, and the Immediately schedule setting is only available with them. [3]
A useful mental model: polling is you refreshing your inbox every 15 minutes; a webhook is the doorbell.
| Polling trigger | Instant (webhook) trigger | |
|---|---|---|
| How it learns about events | Asks the app on a schedule [2] | The app sends data to a URL when the event happens [1] |
| Typical delay | Up to one schedule interval (default every 15 minutes in Make) [4] | Runs as data arrives [1] |
| Runs with no new data | Yes; logged as a check run in Make [2] | No request, no run |
| Setup effort | Pick the app and the interval | The sending app must support webhooks, or you paste the URL into its settings |
| Main risk | Paying for empty checks; delay | Bursts, duplicates, a leaked URL |
Why webhooks usually save Make credits
Make bills in credits, and its help page says 1 operation equals 1 credit by default for non-AI apps. [5] Its scheduling guide gives the cost of the trigger module alone on a timer: running every 5 minutes is 288 credits per day, every hour is 24 credits per day (720 per month), and once daily is 30 credits per month. [4] The rest of the scenario uses more credits depending on how much new data each run processes. [4]
Worked example: a contact form gets about 20 submissions a day. On a 15-minute poll, the trigger checks 96 times a day, which by Make's formula is roughly 2,880 trigger credits in a 30-day month before any action runs. With an instant trigger, there are no scheduled checks; the scenario starts about 20 times a day, and you pay for the modules in those 20 runs. The fewer events you get relative to your check interval, the bigger the saving.
When polling is still fine: the source app has no webhook option, you only need a once-a-day batch, or the events arrive constantly anyway, so almost every check finds data.
How Pabbly Connect counts the same thing differently
Pabbly Connect does not bill the way Make does. Its pricing FAQ says triggers are not included in the task count and only action steps are counted, and internal steps such as filters, routers and formatters are not counted either. [6] The same FAQ says each check made to an external app for new data counts as an operation, so a check every 5 minutes is 288 operations a day whether or not there is new data, and states that Pabbly does not charge for operations. [6]
In practice, that means switching from polling to a webhook in Pabbly mostly changes how fast the workflow reacts, not how many tasks you use. In Make, the same switch can change your bill. Do not compare a Pabbly task allowance and a Make credit allowance one-to-one; count each workflow in each platform's own unit.
What happens to webhook data in Make
Each Make webhook has its own queue. [1] Instant webhooks are processed in parallel by default; turning on Process data in order makes each run finish before the next starts, which matters when order is important, such as a create event followed by an update. [1]
Queue size scales with your plan: Make says that for every 10,000 credits licensed per month you can have up to 667 items in each webhook's queue, with a maximum of 10,000. [1] When the queue is full, Make rejects extra data. Data in the queue is permanently deleted as soon as a scenario processes it, and webhook logs are kept for 3 days (30 days on Enterprise). [1]
| Status code Make returns | Meaning [1] | What to do |
|---|---|---|
| 200 Accepted | Request received | Nothing; check the run in history |
| 400 Queue is full | Queue limit reached | Find why the scenario is not draining the queue |
| 429 Too many requests | More than 300 requests in 10 seconds | Ask the sender to retry with a delay, or batch events |
| 410 Gone | Webhook deactivated after 5 days unattached | Create a new webhook and update the sending app |
Test a webhook safely before going live
The goal of testing is to see the exact data shape once, with a record that cannot hurt anyone, before a real customer's data flows through every downstream step. The steps below are our recommended routine, built around the behaviors Make documents.
- Create the webhook in a copy of the scenario, or with downstream actions pointed at a test sheet, test list or your own email address.
- Send one fake event from the source app, such as a form submission using an address you own. Check that the run appears and the fields arrived with the names you expect.
- Decide on order: turn on Process data in order if a later event depends on an earlier one. [1]
- Decide what the sender sees: without a Webhook response module, Make answers 200 Accepted on receipt, not after your actions succeed. [1]
- Add a duplicate guard (a search-before-create step or a unique ID check) if the sending app may retry the same event.
- Keep the URL private, and delete webhooks you no longer use rather than leaving them in old apps; Make deactivates hooks unattached for 5 days anyway. [1]
- Only then switch the downstream steps to the live list or sheet, and watch the first few real runs in the log within the 3-day log window. [1]
Who should care and who can skip this
Care about webhooks if you are on Make's credit-based billing and have scenarios polling every few minutes for events that happen a few times a day, or if a delay of 15 minutes is unacceptable (for example a booking confirmation). Our Make polling budget guide shows how to price the checks you already run.
You can skip the switch if your workflow runs once a day on a batch, your source app only offers polling, or you are on Pabbly Connect and happy with the reaction time, since triggers do not count as tasks there. [6]
Questions before you decide
Does a webhook cost nothing to run in Make?
No. A webhook removes the scheduled empty checks, but each run still uses credits for the modules it executes. Make says most non-AI operations use 1 credit each.
Is the webhook URL a secret?
Treat it like one. Make describes a webhook as a URL that an external app, service or another scenario can call to trigger a scenario, so anyone who has the address can send data to it. Do not paste it into public pages, forum posts or shared screenshots.
What happens if a webhook receives a burst of events?
Make queues them. Its help page says Make can process up to 300 incoming webhook requests per 10-second interval and returns status 429 beyond that, and a full queue returns 400 Queue is full.
Why did my old webhook stop working?
Make deactivates webhooks that are not connected to any scenario for more than 5 days (120 hours). A deactivated hook returns 410 Gone, so the sending app needs a new URL.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- Make Help: Webhooks Accessed 29 Oct 2026
- Make Help: Types of modules Accessed 29 Oct 2026
- Make Academy: Trigger modules Accessed 29 Oct 2026
- Make Help: Schedule your scenario Accessed 29 Oct 2026
- Make Help: Credits Accessed 29 Oct 2026
- Pabbly Connect pricing and FAQ Accessed 29 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.