Avoiding API Rate Limits by Adjusting InvokeHTTP Scheduling

Many APIs enforce strict rate limits. If you call them too fast, they return 429 Too Many Requests. While Clockspring can route 429 responses and you can build retry logic, sometimes the simplest and most effective fix is to slow InvokeHTTP down so it never exceeds the API’s allowed rate in the first place.

Why scheduling matters

InvokeHTTP runs on a timer. If the schedule is too aggressive (for example, every 0.1 seconds), it may send far more requests than the API allows.

Example:
API limit: 120 requests per minute
Flow schedule: 0.1 seconds
Actual throughput: 600 requests per minute

You’ll hit 429s constantly.

The easy fix: match your schedule to the API limit

If the API allows 120 requests per minute, that’s one request every 0.5 seconds.

Set InvokeHTTP’s Run Schedule to:
.5 sec

This spaces requests evenly so you naturally stay under the API’s threshold.
You get fewer 429s and far less wasted retry traffic.

When this approach is best

Use a slower schedule when:

• You’re calling a rate-limited endpoint

• You don’t need max throughput

• You want predictable pacing

• Retry storms are slowing down the flow

Most APIs prefer steady, controlled traffic over bursts followed by retries.

When you still need 429 routing

Even with a reduced schedule, 429s can still happen. Keep the relationship for 429 in place so you can:

• Log them

• Add a Wait/Notify step

• Back off temporarily

• Collect metrics on how often you’re hitting limits

But the goal is to make 429s the exception, not the normal path.

Quick calculation guide

You can use this simple rule:

Run Schedule (seconds) = 60 / allowed requests per minute

Examples:

• API allows 60 requests/min → schedule = 1 second

• API allows 300 requests/min → schedule = 0.2 seconds

• API allows 10 requests/min → schedule = 6 seconds

Summary

Routing 429s works, but preventing them works better.
If you know the API’s rate limits, set your InvokeHTTP schedule so you never exceed them. This reduces retries, smooths load, and typically results in higher real throughput.