Batch them. Looping one call per identifier is the single most common inefficiency in scripts hitting a data API, and it is usually unnecessary: most well-built APIs accept a comma-separated list in one request. Roughly one caller in five has found this; the rest are still looping.
Two things make it worth more than it looks. It is easier on your code (one request, one response, one error path), and it costs one request against your rate limit instead of forty - which is why batching is the real cure for a 429, not slowing your loop down.
On the TigZig MF NAV API concretely: up to 50 identifiers per call, and you can mix AMFI scheme codes and ISINs in the same list.
https://api.tigzig.com/mf/v1/nav?scheme=120468,119723,INF174K01LT0&since=2024-01-01Three accommodations worth knowing, because they remove the guesswork: scheme, schemes, isin and isins all do the same thing and the names are case insensitive, so you do not have to remember which one; the identifiers themselves are case insensitive too (a lowercase ISIN is fine); and if your HTTP library sends the same parameter twice (some do when handed a list) the values are merged rather than one overwriting the other.
Read the response shape. A single identifier returns the same flat response it always did. Send more than one and you get a wrapped response with everything under schemes and anything unresolved listed separately under not_found - so you know exactly which identifier was the problem instead of failing the whole call. (A good batch endpoint should never let one bad identifier take down the good ones alongside it.)
Then add incrementality. NAVs publish once a day, so after the first load there is nothing to gain from re-fetching all of history every morning: send since= with your last-fetch date and take only the new rows. Batch plus incremental turns a fifty-fund daily tracker into one small request. Going further - byte-range reads, change checks, the bulk file - is here. Full API list: https://www.tigzig.com/apis.