API Rate Limits Explained

A rate limit caps how many requests one caller can make in a given time window, say 600 requests per minute. It's not about the total volume of business you're allowed to do. It's about the rate a shared system can absorb from one source, without one integration's traffic pattern slowing service down for everyone else on it.

This matters more than it sounds like it should, because most integrations don't hit a limit by doing a lot of legitimate work. They hit it from a bug. A retry loop with no backoff, a polling job that fires every second instead of every minute, or a script accidentally run twice can turn a normal integration into something that looks, from the API's side, indistinguishable from abuse. A rate limit is what catches that before it becomes an outage instead of just a warning.

Designing an integration that never trips one

• Poll on an interval that matches how often the data actually changes, not as fast as your code can loop. Stock and pricing rarely need sub-second polling to feel current to a human on the other end.
• Batch instead of looping per item. A single request that updates 50 products counts once against a rate limit. 50 separate requests count 50 times for the same amount of work.
• Back off on failure, don't retry immediately. A request that fails for any reason and gets retried in a tight loop is the single most common way to accidentally trip a limit. Add a short delay, and increase it if the failure keeps happening.
• Cache what you can. If five parts of your own system all want the same product data, one shared cache reading from the API is one request. Five independent callers is five, for an answer that was the same all five times.

What a 429 actually means

A 429 Too Many Requests response means exactly what it says. Nothing's broken - this caller has just used up its budget for the current window. A well-behaved API returns a Retry-After header telling you how long to wait before the next attempt will be allowed. The correct response is to wait that long, not to immediately retry and burn another rejected attempt for no benefit.

If legitimate traffic is genuinely hitting the limit, not a bug, just real growth, that's a signal to either optimize the integration (batching, caching) or move to a plan with a higher budget. It's not a signal to work around the limit some other way.

How Feedwyre handles this

Every plan has a per-tenant requests-per-minute budget, shared across all of that tenant's API keys combined rather than per key, so creating more keys doesn't raise the effective ceiling. A throttled request returns 429 with a Retry-After header, and crucially, it doesn't count against your monthly query usage. An attempt that was actually rejected is never billed as a call. Higher tiers get a higher per-minute budget, sized for a real integration's occasional burst (a bulk price sync, say) while still stopping runaway volume.