---

If there is one universal truth in B2B automation, it is this: You will eventually hit an API Rate Limit.

When you are trying to sync 10,000 records from Airtable to HubSpot, your iPaaS platform (like Make.com or n8n) can process the loop in milliseconds. However, the receiving servers will immediately block your IP, returning an HTTP 429 Too Many Requests error, crashing your workflow halfway through.

Instead of digging through 14 pages of developer documentation every time you connect a new tool, use the instant search directory above to find the exact rate limits, pagination rules, and headers for the most popular B2B APIs.

Why Every B2B Automation Needs Rate Limit Buffers

When you look at the database above, you will notice that limits vary wildly. Airtable allows a measly 5 requests per second, while Salesforce limits you to 100,000 requests per rolling 24 hours.

To prevent your webhooks from failing in production, you must implement Sleep Timers (throttling) in your loops.

For example, if Shopify allows 40 requests per minute, that translates to 1 request every 1.5 seconds. If your Do/While loop or Iterator does not pause for 1,500 milliseconds between executions, you will get blocked.

Need to calculate the exact math? Use our API Rate Limit & "Sleep" Calculator to generate the exact Node.js delay code for your automation.

REST API "Requests" vs. GraphQL "Cost Points"

If you search for Shopify in the tool above, you will notice two different entries. This is because standard REST APIs and modern GraphQL APIs calculate rate limits completely differently.

Standard REST APIs (The "Leaky Bucket")

Most B2B platforms use a "Leaky Bucket" algorithm. Imagine a bucket that holds exactly 40 drops of water (40 requests). If you make 40 requests instantly, the bucket is full, and any further requests spill over (throwing a 429 error). However, the bucket has a leak at the bottom, draining 2 drops every second. As long as you don't pour data in faster than it drains, you will never hit a limit.

GraphQL APIs (Cost Points)

GraphQL allows you to fetch incredibly complex, nested data in a single call. Because one request could potentially ask the server for 50,000 lines of data, GraphQL APIs do not limit the number of requests. They limit the Computational Cost.

Every field you request has a point value. A standard query might "cost" 15 points. If your limit is 1,000 points per minute, you must calculate the cost of your specific JSON query before deciding how fast your automation can loop.

The X-RateLimit-Remaining Header Trick

Hardcoding a Sleep(2000) node into your workflow is the safest way to prevent rate limits, but it is also the slowest. It forces your automation to pause even when the API is perfectly happy to accept more data.

Advanced RevOps engineers use Header Polling to build self-adjusting automations.

If you search for HubSpot in the tool above, you will see the header: X-HubSpot-RateLimit-Remaining.

Every time you make a successful HTTP request, the API sends a hidden "Header" back in the response. This specific header tells you exactly how many requests you have left in your current 10-second window.

The Pro-Level Make.com/n8n Architecture:

1. Make your standard HTTP Request.
2. Read the X-RateLimit-Remaining header in the output.
3. Add an IF/Router statement: If Remaining Requests < 5, trigger the Sleep Node for 10 seconds. Else, continue instantly.

This allows your automation to sprint at maximum speed, pausing only when it is in imminent danger of hitting a 429 error.

Handling Concurrency in Zapier and Make.com

A hidden trap in automation is Concurrency.

Let's say you build a Zap that triggers every time a customer submits a Typeform. It works perfectly in testing. Then, you launch a marketing campaign, and 50 people submit the form at the exact same second.

Zapier will instantly spin up 50 simultaneous (concurrent) executions of that workflow, firing 50 identical API requests to your CRM at the exact same moment. If your CRM (like Mailchimp) limits you to 10 concurrent connections, 40 of those leads will vanish into thin air.

If you anticipate massive traffic spikes, you must migrate away from instant webhooks and utilize Message Queues (like AWS SQS, RabbitMQ, or Make.com's sequential webhook processing) to force those 50 executions to wait in a single-file line.

---

Tired of building fragile integrations? Stop hard-coding sleep nodes. Download our architecture blueprints for building self-healing, auto-throttling data pipelines in Make.com and n8n.