Because WEBSERVICE is a volatile function. It recalculates on any change anywhere in the sheet - not just when its own inputs change - so a few hundred of those cells all fire at the same instant. Any API with a per-IP rate limit will refuse most of that burst with a 429, which simply means too many requests arriving at once. Your formulas are not wrong; the calling pattern is.
It is also a pattern you cannot tune your way out of: one WEBSERVICE cell is one request, and the function has no way to batch or to wait. Spreadsheet clients hit rate limits harder than scripts for exactly this reason.
Three fixes, roughly in order.
1. Use a batching endpoint. If the API accepts several identifiers per call - TigZig's Yahoo Finance endpoint takes up to 25 tickers in one request - a few hundred names becomes a few dozen calls instead of a few hundred. Be realistic about time: with hundreds of symbols that can still take minutes, because a well-behaved backend paces its own calls to the upstream provider rather than hammering it.
2. Move to Power Query (M). The calls run in order and refresh when you ask them to, not on every keystroke. That single change removes the burst.
3. Move to Python in Excel (xlwings Lite). Same benefit as Power Query, plus real control over pacing, retries and error handling - and you can write the results wherever you want. Either option is straightforward to set up with an AI assistant; a regular ChatGPT will happily write the M or the Python for you and tell you where to paste it.
The general principle behind all three: batch your identifiers and control when the calls run. More on what a 429 means and how to recover: https://www.tigzig.com/agents-faq/why-do-my-api-calls-time-out-or-return-429-in-a-batch. Free xlwings guides and templates: https://www.tigzig.com/xlwings-starter. Full write-up: https://www.tigzig.com/post/yfin-excel-webservice-429s-aug2026.
← All Agents FAQ