Every external API a system depends upon imposes limits on how frequently it may be called, and treating those limits as an afterthought is a reliable way to produce brittle automations. The thesis of this article is that respecting rate limits is both a technical requirement and a matter of good citizenship: a well-behaved client adapts its request rate to the signals the server provides, recovers gracefully from rejection, and avoids amplifying transient failures into outages. The mechanisms for achieving this are well established, and applying them consistently is the mark of a robust integration.
How Servers Communicate Limits
APIs express their constraints through HTTP. The primary signal is the 429 Too Many Requests status code, which indicates that the client has exceeded its allowed rate. Servers frequently accompany this with a Retry-After header specifying how long the client should wait before trying again, expressed either as a number of seconds or as an HTTP date. The 503 Service Unavailable status carries a similar meaning when the server is temporarily overloaded.
A disciplined client reads these signals rather than ignoring them. When a Retry-After value is present, it is authoritative and should be honoured directly; the server has told you precisely when to return. Many providers also expose remaining-quota headers on successful responses, allowing a client to slow down proactively before it is rejected rather than reactively after. Designing around these signals means the server’s intent, not guesswork, governs the client’s pacing.
Exponential Backoff and Jitter
When a request fails transiently and no explicit Retry-After is provided, the correct response is to wait and try again, but not immediately and not at a fixed interval. Exponential backoff increases the delay between successive attempts, typically doubling it each time: one second, then two, then four, and so on, up to a sensible ceiling. This gives an overloaded service room to recover instead of being struck by a steady barrage of retries.
Backoff alone, however, has a failure mode. If many clients fail simultaneously and all back off by the same schedule, they will retry in synchronised waves, recreating the very congestion they were meant to relieve. The remedy is jitter: adding a random component to each delay so that retries spread out across time. Exponential backoff with jitter is the standard recommendation precisely because it both relieves pressure and decorrelates clients. A retry policy should also cap the number of attempts and distinguish retryable errors, such as 429 and 503, from permanent ones, such as 400 or 401, which retrying will never resolve.
Throttling in Automation Platforms
These principles apply equally to low-code automation tools, where the temptation to fire requests as fast as a workflow can iterate is strong. In n8n, for example, a workflow that loops over a large dataset can easily exceed an API’s limits unless it is deliberately paced. The platform provides mechanisms for this, including batching items so that requests are issued in controlled groups and inserting deliberate waits between batches. Configuring an HTTP request node to respect concurrency and to pause between iterations transforms a workflow from a source of 429 responses into a well-mannered consumer.
The general principle is to control the rate at the point of egress. Whether in hand-written code or a visual workflow, requests should pass through a throttle that bounds how many are in flight and how rapidly they are dispatched, with retries layered on top to handle the rejections that still occur.
Designing for Cooperation
Rate limiting is ultimately a shared resource problem. A client that hammers an endpoint degrades service for everyone, itself included, and often invites stricter limits or outright blocking. A client that paces itself, honours the server’s signals, and backs off under pressure preserves the relationship and its own reliability. The cost of implementing these behaviours is modest; the cost of omitting them is failed jobs and damaged trust.
Conclusion
Being a good API citizen means treating rate limits as a contract to be observed rather than an obstacle to be overrun. Read the 429 status and the Retry-After header, apply exponential backoff with jitter when no explicit delay is given, distinguish retryable from permanent errors, and throttle egress whether in code or in a platform such as n8n. These practices cost little to adopt and yield integrations that remain stable under load, recover cleanly from disruption, and respect the services they depend upon.