Integration · Zapier
Zapier meters by the task — one successful action step. Triggers, filters, paths, Formatter and Delay are free; every successful action is not. Runs are held rather than lost when you exceed your plan, then replay at one per second, and workflows halt entirely at three times your limit.
Every line above is Zapier’s own documentation, fetched 1 September 2026, linked so you can check it yourself. 5 of the 13 fields are not published at all — those are marked, and they are the ones that cost you time. The full capability register puts this beside the other eight.
The hosted automation layer with the largest app catalogue. Where most small businesses start, and the right answer more often than a custom build.
Everything in the strip above is Zapier’s own published documentation, fetched 1 September 2026 and linked to the page it came from. We have not paraphrased it into something friendlier, because the exact wording is what you need when a limit bites at four in the afternoon.
What follows is what those facts mean for a build — the constraints that change a design decision rather than the ones that are merely true. If you want the same treatment for the other eight systems side by side, that is the capability register. If you want to know whether we have built against both sides of a particular pairing, the integration checker answers that specific question.
This is the single most useful thing to understand about Zapier economics and most people have it slightly wrong. A task is a successful action that runs. Triggers do not count. Filters and Paths do not count. Formatter, Delay, Looping, Digest, Storage and Zapier Tables steps do not count.
What does count: every successful action step, including steps inside error-handler paths, and — importantly — previously successful steps that rerun when you do a full replay. A search action set to "proceed if nothing found" costs one whether or not it finds anything. Zapier MCP tool calls cost two. Lead Router costs five per successful lead.
So a Zap with a trigger, three filters and two actions costs two tasks, not six. And a Zap with a trigger and eight actions costs eight — every single time it fires. The arithmetic that matters is not steps, it is actions multiplied by frequency, and it is worth doing on paper before choosing a plan.
Nothing is lost. Zapier holds runs rather than dropping them, and they replay from Zap History once you have tasks available. That is genuinely well designed and worth saying, because the failure mode most people fear does not happen.
The catch is the replay rate: one per second. A backlog of ten thousand held runs takes about three hours to drain. For a nightly report that is fine. For a lead notification or a booking confirmation, three hours late is the same as never — the customer has already rung someone else. And above three times your plan limit, including pay-per-task usage, workflows stop dead.
The honest boundary is this. Zapier is the right tool when the volume is modest, the logic is linear, and the connectors already exist — which describes most small businesses most of the time, and we will tell you so rather than quoting a build. It stops being the right tool when the same workflow runs thousands of times a month at one task per action, when the logic needs branching that pushes you toward the hundred-step ceiling, or when a private integration on a Professional plan runs into the 100-requests-a-minute cap. The build-versus-Zapier comparison works through where that line sits.
Instant webhook triggers allow 20,000 requests per 5 minutes per user, which is ample. The limits that actually bind are elsewhere: polling triggers recognise at most 100 new items per poll after deduplication, and private apps are throttled to 100 requests per 60 seconds on Free and Professional plans against 5,000 on Team and Enterprise.
That private-app throttle is the one to know if we build you a custom Zapier integration. On a Professional plan it is a hard ceiling of roughly 1.6 requests a second, which is a Team-plan decision dressed up as a technical constraint. Zapier also recommends moving from polling to REST Hook triggers above about 100 records per poll, which is sound advice for the same reason.
One more piece of arithmetic nobody publishes: the pay-per-task rate. Zapier says it depends on your plan and billing cycle and directs you to your own billing settings. So the honest answer to "what does an overage cost" is that you cannot know until you have signed up — worth finding out before you build something with a spiky volume profile on top of it.
| Zapier | |
|---|---|
| Read records on demand | Partly Polling triggers recognise at most 100 new items per poll after deduplication. |
| Write records in | Yes Every successful action costs one task. Private apps are capped at 100 requests a minute below Team. |
| Know the moment something changes | Yes Instant triggers via REST Hooks, 20,000 requests per 5 minutes per user. |
| Verify an event came from them | Not assessed No signature scheme is published for inbound webhooks. |
| Recover after an outage | Partly Runs are held rather than lost, then replay at one per second. Ten thousand held runs is about three hours. |
| Bulk load history | No Not what it is for. Above 100 records per poll Zapier itself recommends moving to webhooks. |
| Keep data in Australia | No Zapier states data is hosted on AWS in the United States. No Australian region is offered. |
5 of the thirteen fields we track are simply absent from Zapier’s documentation: token lifetimes, what happens when a webhook delivery fails, how to verify an event actually came from them, any bulk or batch limit and what the test environment gives you.
This is the part of an integration page that competitors leave out, and it is the part that costs money. An undocumented rate limit is not an academic gap — it means the first time you find the ceiling is in production, on someone else’s business, usually on the busiest day of their month.
We are not going to fill these in with figures from a forum thread. Numbers circulate for most of them, and some are probably right, but we cannot show you where they came from and neither can the person who posted them. When we have measured Zapier properly under load, those figures will appear here with the date we measured them and the conditions we measured them under. Not before.
We have implemented against Zapier in production. That is a real fact and it is also a limited one — it tells you we have solved this system's problems before, and it does not tell you how fast, how reliably, or at what volume.
The honest position is this. Everything on this page above the line is the vendor's published documentation, which we fetched, dated and linked rather than paraphrased. Nothing on this page is a Kindra measurement, because our measured register is not finished and publishing half of it dressed up as all of it would make this page less useful, not more.
What we would do on an engagement is measure the specific things that matter for your build — the endpoints you depend on, at your volume, with your data — and hand you those numbers whether or not they suit us. If they say the integration is harder than we quoted, you get told that too. Start with a Leak Check, or read how we work first if you would rather know the shape of it before talking to anyone.
Because it is often the better answer, and because recommending a build to someone who did not need one is how you end up with an unmaintained system and an unhappy client. If your volume is modest, your logic is linear and the connectors exist, Zapier will do it faster and cheaper than we can, and the money is better spent elsewhere. We would rather tell you that and be worth calling when the situation actually changes.
Very often, yes — and if it is, we will say so and there is no engagement. Zapier is a mature product that solves the problem it was built for. Integration work is only worth paying for when the cost sits between systems: the same information being typed into Zapier and then into something else, or a decision waiting because two systems disagree. If everything you need lives inside Zapier, buy the plan that fits and spend the money elsewhere.
They will. Three of the nine systems in our register shipped a breaking or cost-changing update in the last twelve months. What matters is not preventing that — nobody can — but whether the integration was built so the change is a contained fix rather than a rebuild, and whether anyone is watching for the deprecation notice. You own the code either way, so you are never stuck with us to get it fixed.
20 minutes. We find where the money's going. No pitch.
Book a free Leak Check