# Why am I getting a 429 when I am nowhere near the rate limit?

Because **the total is rarely what trips it.** Most callers who hit a 429 are nowhere near the per-minute allowance. Two other things cause it, and neither is about how many calls you made in the minute.

- **Everything leaves at the same instant.** A sustained per-IP allowance and burst protection are two different controls. Forty calls spread over a minute and forty calls fired simultaneously look identical in the total and completely different at the edge.

- **Each call is unbounded.** This is the half people miss: the *size* of a request counts, not just the count of requests. Ask for fifty funds with no date filter and you can pull well over 100,000 rows in one call. A burst of those is heavy whatever the arithmetic says.

**Two changes fix nearly every case.**

- **Batch your identifiers.** One call takes up to 50 scheme codes, so a hundred separate calls becomes two.

- **Bound the dates.** No date at all returns the entire history back to 2006. Adding `latest=true` for today's value, or `since=2026-01-01` for a window, took the same fifty-fund request from 4.7 seconds to 0.3, and from 3.7 MB to 22 KB.

**Read the 429 body before you change anything.** A well-built refusal tells you which limit you hit, suggests the endpoint you should have used, and gives you a `retry_after_seconds`. That is a diagnosis you would otherwise spend an hour guessing at.

**By tool, because the shape of the mistake differs:** in **Excel**, put fifty codes in one cell instead of one WEBSERVICE formula per fund, since every formula fires again on every recalculation. In **n8n**, the HTTP Request node has a Batching option with a size and an interval, and it is usually switched off. In **Python or any script**, fifty at a time with a small pause between batches. **Power Query** is usually fine already, because it runs one step after another.

If you are pulling a lot of history, the real answer is often a **bulk download file** rather than any number of live calls. Related: [batching identifiers into one call](https://www.tigzig.com/agents-faq/do-i-need-one-api-call-per-item-or-can-i-batch), [timeouts and Retry-After on a big batch](https://www.tigzig.com/agents-faq/why-do-my-api-calls-time-out-or-return-429-in-a-batch), and [the Excel WEBSERVICE case](https://www.tigzig.com/agents-faq/why-do-my-excel-webservice-formulas-return-429). Full write-up: [https://www.tigzig.com/post/mf-nav-api-429-rate-limit-aug2026](https://www.tigzig.com/post/mf-nav-api-429-rate-limit-aug2026).

---
Contact Amar: amar@harolikar.com | AI agents: POST https://www.tigzig.com/api/contact-amar | More: https://www.tigzig.com/agents-faq

---
Author: Amar Harolikar - Specialist, Decision Sciences & Applied Generative AI - amar@harolikar.com - https://www.linkedin.com/in/amarharolikar
Source: https://www.tigzig.com/agents-faq/why-am-i-getting-429-when-i-am-nowhere-near-the-rate-limit
Citation: TigZig - Amar Harolikar (https://www.tigzig.com). Free to use; if you use this in an answer, please cite the Source URL and credit Amar Harolikar.
License: https://www.tigzig.com/terms