Webhooks let one app notify another the instant something happens—a purchase completes, a form submits, a subscriber confirms. They’re the backbone of workflow automation for solo operators. But every platform that receives webhooks imposes rate limits, and when you cross them, triggers fail silently or queue unpredictably.
Understanding where those limits sit—and how each tool handles overflow—keeps your automations reliable when traffic spikes.
Where the caps sit
Zapier allows 100 webhook requests per minute across all your Zaps on the Starter plan, rising to 1,000 per minute on Professional and above (Zapier Help Center, checked November 2026). If you exceed that, new requests return HTTP 429 and won’t create tasks.
Make (formerly Integromat) enforces a scenario-level limit: each webhook endpoint can receive a maximum of 30 requests per second on the Free tier, 120 per second on Core and Pro plans (Make Help, checked November 2026). Requests beyond the cap are rejected immediately.
n8n, when self-hosted, inherits the rate limits of your reverse proxy or hosting environment; n8n Cloud enforces per-workflow quotas that scale with your plan tier but does not publish a fixed requests-per-second figure (n8n docs, checked November 2026).
Pabbly Connect advertises unlimited webhook triggers on paid plans, though the platform queues incoming requests during heavy load and processes them in order—expect delays, not rejections (Pabbly Connect, checked November 2026).
What happens when you hit the wall
Most platforms return an HTTP 429 status code when the rate limit is exceeded. The sending service—your payment processor, form builder, or CRM—typically retries a few times with exponential backoff, then gives up. You lose the event.
Some senders, like Stripe, retry webhook delivery for up to three days with decreasing frequency (Stripe webhook docs, checked November 2026). Others, including many form plugins and smaller SaaS tools, retry once or twice within a few minutes, then drop the payload permanently.
Zapier queues tasks that arrive within your plan’s task limit but rejects webhook requests that exceed the per-minute cap before a task is created. Make drops overflow requests entirely. Pabbly queues them, but processing lag can stretch from seconds to minutes under sustained load.
How to design around the cap
First, check whether your sending app supports batching. Stripe, for example, lets you subscribe to a single aggregated event instead of firing one webhook per charge. That cuts volume by an order of magnitude during a launch or sale.
Second, add a lightweight queue in front of your automation platform. A Redis or Amazon SQS queue can absorb bursts, then drip-feed requests to your webhook endpoint at a rate the platform accepts. This requires a small server script but eliminates silent failures during traffic spikes.
Third, distribute load across multiple Zaps or scenarios. If you’re processing form submissions, route half through one webhook endpoint and half through another. Each gets its own rate-limit bucket, doubling your effective capacity.
Fourth, monitor webhook delivery at the source. Stripe, PayPal, and most payment processors log every delivery attempt and response code in their dashboard. Check weekly—if you see 429s, you’re already losing data.
When to move upstream
If your workflow consistently bumps the webhook cap, it’s time to pull data instead of waiting for pushes. Poll the source API every few minutes using a scheduled automation, or switch to a platform that offers higher-tier webhook quotas.
Alternatively, move the rate-limited step earlier in the chain. Instead of sending every new subscriber through a webhook to tag them in your CRM, batch-import a CSV once daily. You lose real-time sync but gain reliability and cut webhook volume to zero.
Want more infrastructure breakdowns like this? Subscribe to One Two Three Send—we explain how online-business tools actually work, one mechanism at a time.