At 3:14 AM on Black Friday, a high-volume Shopify store’s webhook pipeline silently collapsed. Over 4,200 customer order webhooks hit a custom Make.com scenario in under six minutes, triggering an immediate wall of HTTP 429 status codes.
By sunrise, hundreds of unfulfilled orders sat frozen in queue, customer support channels were flooded, and the business was losing thousands of dollars every hour because nobody had configured an error handler for API throttling.
[ Incoming Webhook Flood ] ---> [ Make.com Instant Trigger ] ---> [ Target SaaS API Endpoint ]
│
(429 Error Triggered!)
│
▼
❌ Scenario Instantly Suspended
If your scenarios are crashing with a RateLimitError or your custom HTTP endpoints are returning "429 Too Many Requests", you are experiencing one of the most frustrating bottlenecks in cloud automation. The good news? It is entirely preventable once you understand how request queues, execution limits, and API backoff directives operate under pressure.
In my 15 years of configuring distributed cloud architectures and troubleshooting automation pipelines for enterprise clients across the US, UK, and Europe, I have seen the HTTP 429 error break everything from simple lead routers to complex multi-app syncs.
This comprehensive guide breaks down How to Fix Make.com Webhook Error 429, why these rate limits trigger, and the exact architectural patterns you need to deploy today to keep your automated workflows running smoothly.
Part 1: What Causes Make.com Webhook Error 429?
Before diving into solutions, we need to demystify what an HTTP 429 error code actually signifies.
An HTTP 429 Too Many Requests response is a standardized safety guardrail. It tells an incoming client (or an outgoing Make.com module) that it has exceeded the allowed number of API requests within a specific window of time.
+-----------------------------------------------------------------------------------+
| THE TWO FACES OF ERROR 429 IN MAKE.COM |
| |
| SCENARIO A: INBOUND WEBHOOK LIMIT (Make.com Gateway) |
| [ External App / Script ] ──(Too Many Posts/Min)──> [ Make.com Custom Webhook ] |
| ❌ Make Returns 429 |
| |
| SCENARIO B: OUTBOUND MODULE LIMIT (Target API) |
| [ Make.com Scenario ] ──(Rapid API Requests)──> [ Google Sheets / Airtable / AI ]|
| ❌ Target App Returns 429 |
+-----------------------------------------------------------------------------------+
When dealing with Make.com (formerly Integromat), Error 429 happens in one of two distinct directions:
1. Inbound Webhook Rate Limits (Make.com Receiving Too Fast)
When an external application, server, or custom Python script blasts data into a Make.com custom webhook at a rate higher than your organization tier allows per minute, Make’s inbound edge gateway returns an HTTP 429 error back to the sender.
2. Outbound Module Rate Limits (Target SaaS App Throttling Make)
Your Make.com instant webhook scenario triggers successfully, but a downstream module—such as Google Sheets, Airtable, Notion, or an LLM API endpoint—gets overwhelmed. The target platform sends an HTTP 429 response back to Make.com. Without proper error routing, Make pauses or disables your entire scenario.
Part 2: Inbound vs. Outbound Webhook Errors
Understanding where the request bottleneck occurs is essential to choosing the right fix.
| Dimension | Inbound Webhook Error 429 | Outbound API Error 429 |
| Where it Fails | At Make.com's entry gateway before scenario logic executes. | At a downstream app module inside your scenario canvas. |
| Who Sends 429 | Make.com infrastructure. | External third-party API (e.g., OpenAI, Google, HubSpot). |
| Primary Cause | Sudden traffic spikes, unthrottled loop scripts, concurrent webhooks. | Processing large data arrays sequentially without delays or bulk modules. |
| Primary Fix | Adjust "Maximum runs per minute", queue requests, or use Data Stores. | Attach a Break or Sleep error handler, or batch operations. |
You can check Our other article
Part 3: Step-by-Step Fixes for Inbound Webhook Throttling
If third-party platforms are receiving HTTP 429 responses when attempting to push data into your custom Make.com webhook URL, use these three practical configurations.
+------------------+ +------------------+ +------------------+
| FIX #1 | --> | FIX #2 | --> | FIX #3 |
| Set Max Runs Per | | Enable Sequenced | | Offload Payload |
| Minute Setting | | Data Processing | | to Data Store |
+------------------+ +------------------+ +------------------+
Fix 1: Configure "Maximum Runs to Start Per Minute"
By default, an instant custom webhook scenario attempts to execute every incoming request concurrently. If 50 webhooks arrive in the exact same second, Make spins up 50 parallel execution threads.
To throttle this rate:
Open your Make.com scenario editor.
Click on the Custom Webhook module (the instant trigger).
Click the Schedule Setting (or the clock/lightning icon near the bottom left).
Locate the field labeled Maximum runs to start per minute.
Set a strict cap (e.g.,
20or30runs per minute).
┌─────────────────────────────────────────────────────────┐
│ Webhook Module Settings │
├─────────────────────────────────────────────────────────┤
│ Webhook Name: [ Order Processing Endpoint ] │
│ Maximum runs to start per minute: [ 20 ] │
│ Process data in order: [ Yes ] │
└─────────────────────────────────────────────────────────┘
This forces Make.com to queue surplus requests in its internal buffer rather than rejecting them with a 429 status code.
Fix 2: Enable "Process Data in Order"
When high-volume systems send requests simultaneously, race conditions occur.
Inside the Webhook module settings, locate Process data in order.
Toggle this switch to Yes.
When enabled, Make processes incoming payloads sequentially in a single thread. This eliminates concurrent execution spikes that trigger account-level rate limits.
Fix 3: Implement an Ingestion-Only Decoupled Architecture
For mission-critical enterprise webhooks where you cannot risk dropping a single HTTP POST request, decouple data ingestion from data processing.
[ Incoming Fast Webhooks ] ──> [ Scenario 1: Webhook Ingestion ] ──> [ Make Data Store ]
│
(Runs every 5 mins)
│
▼
[ Scenario 2: Batch Worker ]
Scenario 1 (Ingestion): Receives the webhook payload and immediately writes the raw JSON directly into a Make Data Store or high-capacity database. This scenario takes under 100 milliseconds to complete and uses minimal resources.
Scenario 2 (Worker): A scheduled scenario runs every 5 to 10 minutes, fetches records from the Data Store in controlled batches (e.g., 20 rows at a time), processes them through external APIs, and deletes the processed rows.
This decoupling completely insulates your webhooks from downstream API rate restrictions.
Part 4: Step-by-Step Fixes for Outbound Module Error 429
If your scenario triggers successfully but fails mid-stream because a downstream module hit an external API rate limit, use these battle-tested error handling fixes.
Fix 1: Attach the "Break" Error Handler Directive
The Break directive is the single most effective tool in Make.com for handling transient HTTP 429 errors. When an API returns a rate limit response, the Break directive catches the failure, stores the execution state, pauses for a set interval, and retries automatically.
[ Module: Update CRM ] ──(Error: 429)──> [ Error Handler Route ]
│
▼
[ Directive: BREAK ]
- Attempts: 3
- Interval: 5 minutes
How to Configure a Break Directive:
Right-click on the module that is triggering the 429 rate limit error.
Select Add error handler.
From the error handler tools panel, select the Break directive.
In the Break settings:
Number of attempts: Set to
3or5.Interval between attempts (minutes): Set to
5or10.
Save your scenario changes.
If an API returns HTTP 429, the scenario will not crash or turn off. Instead, Make moves the execution payload to the Incomplete Executions queue and retries the request automatically using exponential backoff principles.
Pro-Tip: Make sure Store incomplete executions is set to Yes in your Scenario Settings panel. If this setting is disabled, the Break directive cannot save failed executions to the queue.
Fix 2: Insert a "Sleep" Delay Module
If you know an external API allows only 1 request per second (like certain legacy CRM endpoints), insert a deliberate delay before calling the module.
[ Webhook Trigger ] ──> [ Tools: Sleep (3 seconds) ] ──> [ Module: External API Call ]
Click the Tools module in the Make scenario builder.
Choose Sleep.
Drag the Sleep module directly ahead of the API module that triggers the 429 error.
Set the delay duration (e.g.,
3to5seconds).
While this slows overall scenario execution, it guarantees you stay within rate quotas during bulk loops.
Fix 3: Switch to Bulk/Batch Processing Modules
Iterating through a list of 100 customer records individually causes Make to send 100 separate HTTP requests in rapid succession. This is the most common reason people run into How to Fix Make.com Webhook Error 429 issues.
Whenever possible, replace single-record actions with bulk modules:
Instead of: Google Sheets > Add a Row (Runs 50 times inside an iterator).
Use: Google Sheets > Bulk Add Rows (Runs once with a single array payload containing all 50 records).
Using bulk modules converts 50 separate API calls into 1 request, eliminating rate limit throttling instantly.
❌ INEFFICIENT (Triggers Error 429):
[ Array of 50 Leads ] ──> [ Iterator ] ──> [ Google Sheets: Add Row ] (50 API Calls!)
✅ OPTIMIZED (Safe & Fast):
[ Array of 50 Leads ] ──> [ Array Aggregator ] ──> [ Google Sheets: Bulk Add Rows ] (1 API Call!)
Part 5: Code Example — Exponential Backoff for Custom Webhook Scripts
If you are sending requests to Make.com webhooks using custom scripts (Node.js, Python, or cURL), you should build client-side retry logic into your code.
Here is a ready-to-use Python script demonstrating how to catch an HTTP 429 response from Make.com and retry using exponential backoff:
import time
import requests
WEBHOOK_URL = "https://hook.eu1.make.com/your-custom-webhook-id"
PAYLOAD = {"order_id": 98452, "customer_email": "client@example.com"}
def send_webhook_with_backoff(url, data, max_retries=5):
delay = 2 # Initial backoff delay in seconds
for attempt in range(1, max_retries + 1):
try:
response = requests.post(url, json=data, timeout=10)
# If request succeeds
if response.status_code == 200:
print(f"Success! Payload delivered on attempt {attempt}.")
return True
# If rate limited (HTTP 429)
elif response.status_code == 429:
print(f"Received Error 429 (Rate Limit Exceeded). Retrying in {delay}s...")
time.sleep(delay)
delay *= 2 # Double the wait time for exponential backoff
else:
print(f"Server returned HTTP {response.status_code}: {response.text}")
break
except requests.exceptions.RequestException as e:
print(f"Network error encountered: {e}. Retrying in {delay}s...")
time.sleep(delay)
delay *= 2
print("Failed to deliver webhook payload after maximum retry attempts.")
return False
# Execute request
send_webhook_with_backoff(WEBHOOK_URL, PAYLOAD)
Troubleshooting Cheat Sheet: Common Error 429 Scenarios
Watch Out For: Never leave a scenario in an unhandled 429 error loop while testing. If Make receives consecutive failures over several hours, it may automatically deactivate the scenario.
+-----------------------------------------------------------------------------------+
| RATE LIMIT TROUBLESHOOTING CHEAT SHEET |
+-----------------------------------------------------------------------------------+
| SYMPTOM: Webhook returns 429 during marketing campaigns |
| QUICK FIX: Increase "Maximum runs per minute" & enable "Process data in order" |
+-----------------------------------------------------------------------------------+
| SYMPTOM: OpenAI / Gemini module fails mid-scenario with 429 |
| QUICK FIX: Add a Break error handler or insert a 3-second Sleep module |
+-----------------------------------------------------------------------------------+
| SYMPTOM: Airtable / Google Sheets throws rate limit during large updates |
| QUICK FIX: Replace Iterator + Update Row modules with Bulk Update modules |
+-----------------------------------------------------------------------------------+
Frequently Asked Questions (FAQ)
What does Error 429 mean in Make.com?
Error 429 stands for "HTTP 429 Too Many Requests". It indicates that either Make.com or a target app integrated into your scenario has exceeded its allowed number of API calls within a specific time window.
Why does my Make.com custom webhook return HTTP 429 even when traffic seems normal?
If multiple webhooks hit Make at the exact same millisecond, Make attempts concurrent executions. If this concurrency bursts past your subscription tier's per-minute limit, Make's edge server drops surplus requests with an HTTP 429 code. Configuring "Maximum runs per minute" in your webhook module settings fixes this.
How do I stop Make.com scenarios from turning off when Error 429 occurs?
Attach an Error Handler (specifically a Break directive) to the failing module. This catches the HTTP 429 error, stores the failed execution in the queue, and retries automatically after a specified time delay instead of stopping the scenario.
Will upgrading my Make.com subscription plan fix Error 429?
Upgrading your Make.com plan increases your organization's total operations per minute and execution limits, which helps resolve inbound webhook throttling. However, if the HTTP 429 error is sent by an external third-party API (like OpenAI or Shopify), upgrading Make won't help; you must adjust request speeds or upgrade the target app's API tier.
Need Custom Help with Your Make.com Setup?
Learning How to Fix Make.com Webhook Error 429 comes down to balancing data flow and adding proper error handlers. By pacing inbound triggers, adding Break directives, and using bulk modules, you can make your automation scenarios practically bulletproof.
Now it is your turn!
Are you currently dealing with a stubborn Error 429 rate limit on a specific Make.com scenario right now?
Drop a comment below with:
The Trigger App and Target Modules in your scenario setup.
How many requests or rows you are attempting to process per run.
The exact error message text from your scenario logs.
I personally read and reply to every comment. Describe your workflow setup below, and I will help you map out the exact error handling configuration or architecture you need to fix it!