API Rate Limits: How to Design Automations That Don't Break at Scale

What rate limits are and why they matter

Every SaaS API has limits on how often you can call it. These limits exist because:

• Protecting the server from overload
• Preventing abuse
• Ensuring fair usage across customers

If you exceed the limit, the API returns an error (typically HTTP 429 "Too Many Requests") and your automation breaks.

For low-volume automations, you'll never hit limits. For high-volume or complex flows, rate limits become a real constraint you must design around.

---

Common rate limits (April 2026)

Twilio

• SMS: 1 message/second on trial, up to 100+/second on paid with A2P 10DLC approval
• Voice: varies by plan, typically 10-60 calls/second
• HTTP API: 200 requests/second per account

HubSpot

• Starter: 100 requests/10 seconds (10/sec), 250,000/day
• Professional/Enterprise: 120 requests/10 seconds (12/sec), 500,000/day
• Per user: 600 requests/minute across all endpoints

GoHighLevel

• Standard API: not publicly stated; community-reported ~100 requests/minute per account
• Webhook limits: incoming webhooks are generally unlimited, but workflow execution is queued under load

OpenAI

• Free tier: 3 requests/minute, 200 requests/day
• Tier 1 ($5 paid): 500 RPM, 10,000 RPD
• Tier 2+: 5,000-30,000 RPM depending on usage history

Stripe

• 100 requests/second in live mode, 25/sec in test mode
• Bulk operations via CSV for high-volume needs

Salesforce

• 15,000 API calls/24 hours on Enterprise
• 1,000,000 on Unlimited with additional usage

Gmail API

• 1 billion "quota units" per day (each request consumes varying units)
• 250 quota units per user per second

Slack

• Web API: Tier 1 (1/min), Tier 2 (20/min), Tier 3 (50/min), Tier 4 (100+/min) depending on endpoint

Airtable

• 5 requests/second per base
• 100,000/month on paid plans

Apollo

• Varies by plan, typically 60-300 requests/minute

---

Understanding rate limit types

Time-window limits

"100 requests per minute" — hits reset at the start of each minute (or after 60 seconds from first request, depending on implementation).

Concurrency limits

"Maximum 10 concurrent requests." Doesn't matter how many per minute — no more than 10 at any instant.

Quota limits

"10,000 requests per day." Resets daily. No sub-limit on per-second rate.

Weight-based limits

Some APIs (Binance, others) assign different weights to different operations. Heavy queries cost more "points" than light queries.

Most APIs use time-window limits. The others show up in specific platforms.

---

How to handle rate limits

Strategy 1: Exponential backoff

When you hit a 429:

1. Wait N seconds
2. Retry
3. If still 429, wait 2N seconds
4. Retry
5. Continue doubling until success or max retries

Strategy 2: Token bucket / rate limiter

Pre-limit your own requests. If API allows 100/minute, pace your automation at 80/minute to stay below.

Strategy 3: Request queuing

Collect requests into a queue. Dispatch at a fixed rate. Avoids bursts.

Strategy 4: Bulk endpoints

Many APIs offer bulk versions ("create 100 contacts in one request" vs. 100 individual requests). Use them.

Strategy 5: Caching

Don't call the API twice for the same data. Cache responses in your automation tool's data store or your own database.

---

Implementation in Make.com

Built-in retry

Make has built-in error handling. Configure modules to retry N times on error. For 429 errors, this naturally spaces out requests.

Sleep modules

Add "Sleep" modules between API calls in loops:

Iterator (process 100 rows) → API call → Sleep (1 second) → next row

This naturally paces requests at 1/second.

Scheduled scenarios with smaller batches

Instead of one scenario processing 10,000 rows:

• Schedule scenario every 15 minutes
• Process 100 rows per run
• 96 runs/day × 100 rows = 9,600 rows/day
• Spreads load across time, avoids hitting daily quotas

---

Implementation in n8n

Wait nodes

Built-in "Wait" node lets you pause between operations:

Webhook → Loop Over Items → API → Wait (1 second) → Next

Error workflow with exponential backoff

n8n has a proper "error workflow" feature. Assign an error workflow that:

1. Receives the failed execution
2. Waits exponential time
3. Retries the specific operation

Code node rate limiter

For custom logic, a Code node can implement token bucket:

const lastCallTime = $workflow.staticData.lastCallTime || 0;
const minInterval = 1000; // 1 second between calls
const now = Date.now();

if (now - lastCallTime < minInterval) {
  await new Promise(resolve => 
    setTimeout(resolve, minInterval - (now - lastCallTime))
  );
}

$workflow.staticData.lastCallTime = Date.now();
return $input.all();

---

Implementation in Zapier

Zapier's rate limit handling is weaker than Make or n8n. Options:

Delay steps

Built-in "Delay" action. Pause N seconds between zaps running.

Slower zap trigger intervals

Change zap polling frequency from every 1-2 minutes to every 15-30 minutes.

Webhooks instead of polling

If possible, use instant triggers (webhooks) instead of polling. Reduces API calls.

For high-volume automation requiring rate limit handling, Make or n8n are better suited than Zapier.

---

Bulk endpoints to know

HubSpot batch

POST /crm/v3/objects/contacts/batch/create

Create up to 100 contacts in one call. Counts as 1 request, not 100.

Twilio bulk SMS

Send one SMS per call, but Twilio has "Messaging Services" with copilot that automatically distributes across phone numbers to handle bulk sends cleanly.

Salesforce Bulk API

For operations on 10,000+ records. Uses async jobs instead of synchronous API calls.

Google Sheets batch

batchUpdate endpoint updates many cells at once. Use instead of one-call-per-cell.

Stripe list pagination

When listing many records, use cursor-based pagination instead of offset pagination.

---

Common patterns that hit rate limits

Pattern 1: Enrichment loop

"For each of 5,000 leads, call Apollo for enrichment data."

At Apollo's 60-300 requests/minute, that's 17-83 minutes minimum.

Fix: chunk and schedule. 500 leads per run, 10 runs spaced over time.

Pattern 2: Webhook → sync to CRM

"Every new form submission → create contact in HubSpot."

If you get 1,000 form submissions in an hour (burst), you're at 16-17/second. HubSpot's rate limit is 12/second.

Fix: queue in Supabase or a data store, batch-process with backoff.

Pattern 3: Daily full sync

"Every night, sync all contacts between HubSpot and GoHighLevel."

50,000 contacts, two APIs. Without rate limit handling, you'll hit caps.

Fix: incremental sync (only changes since last run), bulk endpoints, proper pacing.

---

Monitoring rate limit usage

Check response headers

Most APIs return headers showing your current usage:

• X-RateLimit-Limit — your total limit
• X-RateLimit-Remaining — how many you have left
• X-RateLimit-Reset — when the limit resets (timestamp)

Log these in your workflows. If Remaining gets below 10% of Limit, slow down or alert.

Proactive alerting

Set up a check: "If any workflow fails with 429 status > 5 times in an hour → Slack alert." Catches issues before they spiral.

---

What NOT to do

1. Retry 100 times immediately. Hammering an API that just rate-limited you guarantees more rate limit errors. Use exponential backoff.

2. Ignore 429 errors. Silent failures mean your data sync is incomplete. Treat 429 as a real error.

3. Assume you'll never hit limits. Limits that feel high at 500 contacts/day become painful at 50,000. Design for growth.

4. Run multiple automations against the same API without coordination. Workflow A and Workflow B both hitting HubSpot = combined rate. Either rate-limit each separately or share state.

---

When to upgrade your plan

If you're consistently hitting rate limits and the API has higher tiers, do the math:

• Cost of higher API tier
• vs. Cost of engineering time to work around limits (exponential backoff, queuing, caching)
• vs. Cost of lost data/errors when automation fails

Usually, upgrading is cheaper than engineering around limits. For HubSpot, moving from Starter to Professional raises both rate and daily limits.

---

Sources

Rate limit data from official documentation:

• Twilio: twilio.com/docs/usage/api
• HubSpot: developers.hubspot.com/docs/api/usage-details
• OpenAI: platform.openai.com/docs/guides/rate-limits
• Stripe: stripe.com/docs/rate-limits
• Salesforce: developer.salesforce.com (API limits)
• Apollo: apollo.io/help/api-rate-limits
• Airtable: airtable.com/developers/web/api/rate-limits
• Slack: api.slack.com/docs/rate-limits

Values are as of April 2026 and subject to change. Always check current docs when planning.

Running into rate limits in your automation stack? Let's talk — I can audit and redesign flows to stay within limits while maintaining throughput.