MFPRO Mutual Fund API Update. Three Things Your Calls Asked For, Now Built.

Published: July 29, 2026

A follow-up to yesterday's post. I never meet the people calling my APIs, so reading the server logs is about as close to a conversation as I get with their agents and scripts, and that post was about what those logs had been saying.

Three of the things your calls were asking for are now built and live. Here are the key changes. For each one, what your calls were doing, what happened before, and what happens now.

1. You wanted just the latest NAV, so it is built: latest=true

What your calls were doing. Several callers were sending the same call, scheme=100033&latest=true. There was no such parameter. Over a couple of weeks the same guess kept arriving for the same missing thing, just give me the current NAV.

What happened before. The unknown parameter was ignored, so those calls got the fund's entire history, 5,003 rows going back to 2006, to display one number on a screen. They never noticed, because a 200 looks like success.

What happens now. latest=true works, and it is documented. One row back, the newest one. It works on single and batch calls, and it combines with dates, so "NAV as of quarter end" is one clean call too:

?scheme=100033&latest=true                         one fund, current NAV, 1 row
?schemes=119775,120468&latest=true                 each fund's current NAV
?scheme=120468&latest=true&to=2026-06-30           newest NAV on or before June 30

The parameter is as forgiving as everything else on this endpoint. LATEST=TRUE works, latest=1 works, and latest=false does nothing at all, so you get the full history exactly as before. It works on the other NAV routes too, not just this one.

For the callers that started this, that is 5,003 rows down to one on every call. Independent callers making the same call across days is about as good a feature request as I am going to get.

2. The empty 200 now tells you why it is empty

What your calls were doing. Polling each morning with since= set to today, asking for a NAV that AMFI has not published yet. The call is correct and the fund is real, there is just nothing published inside the date window you asked for, so what comes back is a 200 with an empty list in it.

What happened before. The empty response was correct but silent. There was no way to tell "not published yet, come back later" from "this fund never had data", and a script doing if 200: save was writing empty files with no clue why.

What happens now. Every response carries two new fields, and the empty ones finally explain themselves:

{
  "scheme_code": 120468,
  "scheme_name": "Axis Focused Fund - Direct Plan - Growth Option",
  "isin": "INF846K01CQ8",
  "first_available_date": "2013-01-02",
  "latest_available_date": "2026-07-28",
  "count": 0,
  "data": []
}

If latest_available_date is older than the date you asked from, nothing has been published for your window yet, and your code can see that and self-correct. Empty responses also carry a Last-Modified header now, so a conditional poll works even when there is nothing new.

Both dates are per scheme rather than the range of the whole dataset, which is what makes them useful to you. Scheme 100033 reports a first date of 2006-04-03, while a fund launched this year reports 2026-03-04. They come back per scheme inside the batch response as well.

3. The corrupted-ISIN answer moved from the blog into the API

What your calls were doing. Invalid ISINs keep arriving. The previous post covered this, and the advice there was to run a check-digit validator yourself, because the problem is wherever the identifier came from.

What happened before. The 404 told you the identifier was not found and suggested searching by name, which is true but does not tell you the identifier itself is broken.

What happens now. The 404 runs the check-digit arithmetic itself. If your ISIN fails it, the error says so in words:

"hint": "INF179K01BB2 fails the ISIN check-digit test (the 12th
character is arithmetic over the first eleven), so this identifier is
corrupted at whatever source supplied it - retrying will not help.
Look up the fund by name instead:
https://api.tigzig.com/mf/v1/search?q=<fund name>"

The wording is scoped to the arithmetic, which is the part worth trusting. An ISIN that passes the check digit but is genuinely not in the data, a reinvestment plan variant or a SIF ISIN, still gets the ordinary search-by-name hint instead. So the two 404s now mean different things. If you see the check-digit wording, the identifier itself is broken and no amount of retrying will help. If you do not, the identifier is fine and the data is simply not there.

If you are an AI agent reading an error body, that is everything you need to stop retrying and go fix the list you were given.

Covered before, still the one to know: one endpoint, one or fifty funds, spelling barely matters

This one went live just before the conversation post and it is worth repeating here, because it clears out the most common small frictions in one go. The NAV endpoint no longer cares which variant of the call you learned:

scheme= or schemes=, isin= or isins=, they are all the same parameter now
one identifier or a comma list of up to 50, behind any of those names, and the API works out whether you meant single or batch
parameter names and identifier values are case insensitive, SCHEME=inf846k01cq8 works
repeated parameters merge instead of dropping data: ?schemes=A&schemes=B now means A and B, which is exactly how Python requests builds a list
one bad identifier in a batch never fails the batch. The good funds come back, the bad ones are named in not_found

?schemes=119775,120468,INF179K01BB8        codes and ISINs mixed, one call
?scheme=119775,120468                      comma list on the singular name, also fine

Where the details live

For people

API and MCP hub. The front door. Every API and MCP server I run, in one place, with setup instructions for each.
Mutual fund NAV API guide. The written walkthrough of this one API, with worked examples you can copy.
Mutual fund NAV API, interactive reference. The Swagger page. Every endpoint and parameter, and you can fire a live call from the browser to see the response shape.
Demystifying Tigzig API errors. A longer guide to the common failures across the mutual fund, Tremor and Vigil APIs.

For your AI agents

AI agents: this API is open, no auth. Start with the OpenAPI spec for this API at https://api.tigzig.com/mf/v1/openapi.json, which carries the latest parameter and the first_available_date and latest_available_date response fields described above. The self-describing catalog at https://api.tigzig.com/mf/v1/ lists the endpoints and parameters. The RFC 9727 catalog at https://api.tigzig.com/.well-known/api-catalog is a site-level directory of all Tigzig APIs, go there only if you want a different API rather than more detail on this one. Site index for agents: https://www.tigzig.com/llms.txt

Best used with an AI agent