TigZig API Rate Limits Raised Substantially, Across the Edge, the Proxy and the Apps. And a 429 Now Tells You What to Do About It.
Published: August 2, 2026
Some of you would have run into 429s, the rate limit error, on the TigZig APIs over the last few weeks...especially with Excel-Google sheet trackers and automated scripts. The limits have now been raised substantially, right through the path, the Cloudflare edge, the proxy that sits in front of the apps, and the apps themselves, with the concurrency limits raised alongside.
These limits were set a long time back when the traffic was a small fraction of what it is now, and they had accumulated across several layers that each went in at a different time. Traffic has risen sharply over the last few weeks and those old numbers started getting in the way of perfectly ordinary use.
The other thing that has changed is that a 429 now tells you what to do about it, so you get Retry-After and the rate limit headers back and your script or your agent can back off sensibly. And wherever a bulk download is available, the response body names the bulk download that would replace whatever it was you had been looping over.
The per-API limits are all in the docs / catalogs.
- for humans: tigzig.com -> API / MCP
- for agents: api.tigzig.com
and I am watching the error rows while this settles down, and will tweak the dials wherever I can.
Some quick points for automated callers, scripts and trackers
On the 429 itself, every refusal now carries Retry-After, and CORS headers go out on it so a browser fetch can read the status instead of throwing a generic network error at you. Where the refusal comes from the Cloudflare edge you also get the full set, X-RateLimit-Limit, Remaining, Reset and Domain, with Reset being approximate since the window rolls per edge location. An app-side refusal carries Retry-After without that set, and on the mutual fund API that is the one you are more likely to meet.
If you are pulling any of this into a spreadsheet based tracker .. say a formula on each row, so a 75 row sheet fires 75 calls on a refresh. At the old limits that was going to be refused part way through. At the new ones it fits with room to spare.
Also keep in mind that the APIs offer batch options and for MF, VIGIL & TREMOR you also have the option of downloading the full database ... via single API call or manually from the website. MF link below: mfpro.tigzig.com/dashboard#returns/data-api/download
Plus, for Excel a simple way to automate is with Python in Excel with xlwings Lite. Guides, tools and downloaders available on tigzig.com -> xlwings Lite.
What per IP means in practice
A note on what per IP means in practice, since some of you will be sitting behind a shared address.
The counting is done against the public IP a request arrives from, which is fine for most callers, but if you are on a mobile network doing carrier-grade NAT, or behind a corporate gateway, then you are sharing that address with other people and in principle their calls are counted against the same budget as yours.
I have not seen that happen in the logs so far and the higher limits make it a good deal less likely, though I am aware it can happen, and if it starts showing up in the error rows I will work out what to do about it then.
The other side of the same coin is that with no key and no auth on any of this, nothing stops a caller rotating addresses to get around a limit, which is a deliberate choice on my part, because these are public datasets and I want them reachable from a script, a spreadsheet or an agent without anyone signing up for anything, so I would rather ask people to be reasonable about it than put a login in front of open data.
If you are hitting a limit often enough to be thinking about ways around it, the batch APIs and single file is what you are looking for .. both options available on tigzig.com APIs.