Built and run by one person.
MF NAV API FAQ. Why Am I Getting an Error, Why Is There No SIF NAV, and Why Does the AUM Look Wrong?
Top•MFPRO - Mutual Fund Analytics•MF File Converter•QRep - Security Reports

MF NAV API FAQ. Why Am I Getting an Error, Why Is There No SIF NAV, and Why Does the AUM Look Wrong?

Published: August 12, 2026

Related toolsMFPRO - Mutual Fund Analytics•MF File Converter•QRep - Security Reports

Every question here comes from something a real caller actually did or a feedback left on the site. And there have been many ... spanning the past 7 days, 25,000+ API calls and more than 450 files downloaded serving 18+ GB of data.

The dataset: 38,085 schemes, 37.2 million NAV rows, April 2006 to yesterday, including matured and closed schemes. 8,592 are currently live. No authentication, no key, no sign-up.

I passed a SIF identifier and got a 404.

That is correct, not a bug. AMFI's mutual fund feed carries zero SIF schemes, so we hold none. SIF data is published separately at sif.tigzig.com (NAV, scheme master, quarterly AAUM). It is not in the API yet.

w.e.f. 12 August 2026 the API recognises the shape and tells you so in the error response instead of returning a bare 404.

The AUM looks far too low.

It is per scheme, not per fund. Direct and Regular plans, and Growth and IDCW options, are each filed separately with their own AUM. Kotak Arbitrage Fund's Direct Growth scheme is about 43,700 Cr; all four of its schemes together are about 70,900 Cr. Sum the schemes to get the fund.

One fund is returning several rows with different AUMs.

Same reason. Those are its plans and options, each with its own scheme code and its own filing. They are not duplicates.

Is the AUM figure a month-end number?

No. It is AMFI's quarterly average of daily net assets. Compared against a month-end figure it will differ by a few percent in either direction.

The AUM looks out of date.

Check the quarter column on the row. Schemes move to a new quarter as AMFI publishes, so they are not all on the same one. Today about 97.6% of live schemes are on the latest quarter and 2.4% on the previous one.

A valid ISIN returns nothing.

If it is an IDCW reinvestment ISIN, that now resolves. We map both ISINs to the scheme, and 7,004 schemes carry a second one.

If it still returns nothing the scheme has probably matured. Pass active=all, because filter-only searches default to live schemes.

An IDCW scheme shows roughly 0% return.

NAV-based returns understate IDCW plans, because payouts leave the NAV. Kotak Arbitrage IDCW shows 0.00% over three years on NAV while its Growth twin shows 7.61%. For a like-for-like comparison use the Growth option.

My category filter suddenly returns fewer schemes.

SEBI renamed most categories in February 2026 and AMCs re-file until 26 August, so old and new names are both live. category=Dynamic Bond gives 134, category=Dynamic Term Fund gives 26. Pass both, comma separated, to get all 160.

There is no NAV for the date I asked for.

NAVs exist for trading days only. Asking for a fixed date in a loop silently drops weekends and holidays. Take the nearest earlier date instead of an exact match.

My ISIN is definitely valid, and it still returns nothing.

Work through these in order.

  1. Is it a SIF? SIF identifiers carry "30" in the eighth and ninth characters, for example INF966L30019. Those are real funds with real NAVs, but they live at sif.tigzig.com, not here.

  2. Is it corrupted? Check your ISIN at isin.tigzig.com.

  3. Has the scheme matured? Filter-only searches show live schemes by default. Add active=all.

I am passing a scheme code and getting a 404. The number looks fine.

Real AMFI scheme codes currently run from 100,027 to 154,612. There is nothing below 100,000 and nothing above about 155,000.

My spreadsheet is sending values that are clearly wrong.

If you see #N/A, #REF! or #VALUE! coming back in the error message, your sheet is passing an error cell into the URL as text. The API is receiving exactly what was sent. Guard the cell before the call. In Google Sheets or Excel, wrap the lookup in IFERROR and skip the request when it is blank.

I used /navs and it used to 404.

It works now. The plural is accepted as an alias of /nav.

Do I have to remember exact parameter names?

Mostly no. These all work:

scheme=      or  isin=       (one identifier)
schemes=     or  isins=      (a comma separated list, up to 50)
since= / to= or  start= / end=
q=           or  query= / name= / search=

Parameter names are case insensitive, and so are the identifier values. A comma list in the singular form is treated as a bulk request. Repeated parameters merge, so schemes=A&schemes=B is the same as schemes=A,B.

I mistyped a filter and got a 400 instead of results.

That is deliberate. An unknown parameter name fails loudly with a suggestion, rather than being ignored. If a typo were silently dropped you would receive unfiltered results that look correct and are not, which is far worse than an error you can see.

My dates are being rejected.

Dates must be YYYY-MM-DD. DD-MM-YYYY is rejected rather than guessed, because 01-08-2026 is genuinely ambiguous and picking one reading would corrupt your series without you knowing.

One call returned an enormous amount of data.

A bare request for a scheme returns its entire history, which for an old fund is twenty years of daily NAVs. Narrow it:

latest=true            just the newest row
since= and to=         a bounded window

I need the whole universe. Should I page through search?

No. The limit on search is 100 per call, and the dataset refreshes three times a day, so a long pagination sweep that crosses a refresh can skip or duplicate rows. Use the single file instead:

/mf/v1/download?format=latest

That is one row per scheme with the full scheme master, the latest NAV and the latest quarterly average AUM. There are also full-history downloads in CSV, TSV, Parquet and SQLite.

What are the rate limits?

300 requests per minute per IP on the data endpoints. Downloads are limited separately and more tightly, since the files are large.

How do I tell whether the data has changed since I last pulled it?

The download endpoints support conditional requests. Send If-None-Match or If-Modified-Since and you get a 304 with no body when nothing has changed. /mf/v1/downloads/manifest gives sizes, row counts and a generation timestamp, and is cheap to poll.

The same fund appears under two different scheme codes.

When a fund changes manager, AMFI issues a new scheme code and the ISIN stays with the instrument. So one code gives you only one leg of the history. 799 ISINs sit on more than one scheme code.

To assemble the whole history:

  1. /mf/v1/search?isin=<your ISIN>&active=all - active=all is essential. Without it the matured leg is hidden and you get half the story with no warning.
  2. Pull each scheme code returned.
  3. Compare the NAVs either side of the boundary before joining them.

That last step matters. Usually the NAV runs continuously across the handover, but where units were exchanged at a ratio it jumps, and splicing those blind invents a return nobody earned. Whose track record survives a merger is a regulatory question, not ours to decide, so we publish the raw NAV as filed and leave the judgement to you.

A Gold ETF is filed under an equity category.

That is how AMFI filed it. We publish categories as received and do not correct them, because silently reclassifying someone else's filing would make our data disagree with the official record for reasons nobody could audit.

A matured scheme shows a NAV of 0.00 on its last day.

That is AMFI's terminal marker, published as filed. Filter on the active flag if you only want live schemes.

Some numbers look odd in the older history.

The archive contains a small number of source-filed oddities: a few bad prints, some par-value resets, occasional precision artefacts. Where our pull is faithful to what AMFI published, we do not clean them. They are documented rather than silently corrected.

My download script broke with a KeyError on aaum_cr.

The column was renamed on 12 August 2026:

aaum_cr  ->  aaum_cr_quarterly_avg

Same values, same units, same position. The old name read as though it were today's AUM, which is exactly the misreading this FAQ opens with, so the name now says that it is a quarterly average. Rename the reference; nothing else changed. The companion columns are untouched.

This affects the latest-snapshot files only. Full-history downloads are unaffected.

How will I know if the file format changes again?

/mf/v1/downloads/manifest carries a schema_version number and a short note saying what moved and when. It is currently at 2. If you automate against these files, read that number: it changes only when a column is renamed, removed or changes meaning, never when one is added.

Where to look things up