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, timeouts and Retry-After on a big batch, and the Excel WEBSERVICE case. Full write-up: https://www.tigzig.com/post/mf-nav-api-429-rate-limit-aug2026.