MF NAV API - Free Indian Mutual Fund NAV Data (AMFI)

Know the fund name? Search it:

GET https://api.tigzig.com/mf/v1/search?q=hdfc flexi cap

Returns matching scheme codes and names (e.g. 118955 = HDFC Flexi Cap Fund - Growth - Direct Plan).

SIF. Search covers mutual funds by default. Add source=sif for Specialized Investment Funds (SIF) only, or source=all for mutual funds first and then SIF. q=SIF-120 finds one SIF by its code. SIF rows have source and sif_code.

Do not have a name to search for? Browse instead. The same endpoint filters on scheme metadata, so q is optional - pass filters on their own and you get the matching list back:

GET https://api.tigzig.com/mf/v1/search?category=small cap&plan=direct&option=growth
GET https://api.tigzig.com/mf/v1/search?amc=icici,aditya birla&group=equity&exclude=index
GET https://api.tigzig.com/mf/v1/search?group=equity&first_date_from=2015-01-01&first_date_to=2016-12-31

You can filter on AMC, category group, SEBI sub-category, scheme type, plan, option, ISIN, TXIC code, active-or-matured, and launch / last-NAV date windows. The full list with descriptions is in the API Endpoints reference below. What each of those values means - and the caveats that change how you read it - is in the data dictionary (Markdown twin: https://www.tigzig.com/md/mfpro/data-dictionary.md).

The rules are the same for every text filter: contains-matched and case-insensitive (category=small finds Small Cap Fund), a comma means OR within one filter, different filters AND together, and exclude= is the NOT. Repeating a filter does the same thing as a comma - ?amc=icici&amc=hdfc is identical to ?amc=icici,hdfc, the same merge rule schemes= uses on the NAV endpoints - so a form or client that emits repeated params gets the union rather than losing all but the last one. One scope rule worth knowing before you trust a result: exclude= reads the scheme name and the AMC name only, never the category - so exclude=value drops an index fund with "Value" in its name and does not drop the Value Fund category. To remove a category, select the ones you want with category= instead. A browse with no q returns live schemes by default - add active=all to include matured ones. Page through with limit (max 100) and offset; the response carries total_matches.

Parameter names are strict on this endpoint. An unknown parameter is a 400, not a silent ignore - so a typo like ?catgeory=small can never quietly hand you the wrong universe of funds. The same instinct runs through the rest of the validation: an impossible date window, a non-numeric limit, a blank q, or a scalar parameter repeated with two different values all fail loudly and name the problem, instead of returning an empty or arbitrary result you would have to reverse-engineer.

Guessed a filter value wrong? A zero-match browse tells you the valid values for the filters you used - the category groups, the SEBI sub-categories, plans, options, AMC names - so you can fix the call from the response itself. And the shapes stay predictable: a plain q search returns exactly the compact result it always did, while adding any filter returns a richer row carrying the full scheme metadata (AMC, group, category, plan, option, first and last NAV dates, TXIC code).

Pass one identifier or several - AMFI scheme code or ISIN, mixed freely - and get the ENTIRE history back, no pagination. scheme= takes a single id or a comma-separated list; isin= / isins= work as synonyms. Both identifier styles are auto-detected (numeric = AMFI code, 12-char starting with IN = ISIN). Add &since=YYYY-MM-DD / &to=YYYY-MM-DD to bound the window:

GET https://api.tigzig.com/mf/v1/nav?scheme=118955&since=2020-01-01
GET https://api.tigzig.com/mf/v1/nav?scheme=INF174K01LT0
GET https://api.tigzig.com/mf/v1/nav?scheme=118955&since=2024-01-01&to=2024-12-31

Same call in REST path form:

GET https://api.tigzig.com/mf/v1/schemes/118955/nav
GET https://api.tigzig.com/mf/v1/schemes/INF174K01LT0/nav

SIF. Specialized Investment Funds work on both forms. A SIF code works with or without the prefix (120 or SIF-120), and so does a SIF ISIN. Every mutual fund code is 100027 or above and every SIF code is below 100000. A SIF reply has the same shape plus source: "SIF" and sif_code. SIF NAVs can be a day behind the mutual funds, and latest_available_date shows each scheme's last NAV.

Before computing returns. NAV is as AMFI filed it and is not adjusted for unit splits or face-value changes, so check for a one-day move of more than 2x first. About 400,000 rows have a NAV of 0, from segregated portfolios, wound-up plans and a few filing days. Filter on nav > 0. The API adds a warning to a reply when the rows it returns hold a NAV of 0 or below, or a one-day move of more than 2x. One ISIN can sit on several scheme codes over time. A lookup by ISIN returns the newest code, and an older code's series is reached by its scheme code. About 20 ISINs in the history are not valid ISINs as filed.

Only need the most recent NAV, not the whole history? Add latest=true to get exactly one row per scheme - the latest published NAV. It works on single, bulk and path forms (and is case-insensitive); add &to=YYYY-MM-DD for the latest NAV as of a date, e.g. a quarter-end:

GET https://api.tigzig.com/mf/v1/nav?scheme=100033&latest=true
GET https://api.tigzig.com/mf/v1/nav?scheme=100033&latest=true&to=2026-06-30

An empty window (no rows in your date range, or the day's NAV not published yet) returns count: 0 with that scheme's first_available_date and latest_available_date, plus a Last-Modified header - so a poller learns the real data range without a second call, and can send If-Modified-Since for a cheap 304.

For portfolios and multi-fund analytics, batch up to 50 identifiers (AMFI codes and ISINs can be mixed):

GET https://api.tigzig.com/mf/v1/nav?schemes=118955,120468,INF174K01LT0

Response shape wraps the per-scheme results under schemes with a top-level not_found list for any identifier that did not resolve. An unknown or malformed entry never fails the batch - the valid schemes still come back.

Single and bulk are the same endpoint, recently unified so you never have to pick which form to use. One identifier returns that scheme's rows directly; several (or schemes=) returns the wrapped shape above. Existing single-identifier and bulk calls are unchanged and keep working exactly as before.

If you do not need history, this one file replaces the lot: one row per scheme, 38,000+ rows, 23 columns, about 9.7 MB as plain CSV (1.1 MB compressed). It carries the scheme master, the latest NAV, and each scheme's average AUM together:

GET https://api.tigzig.com/mf/v1/download/amfi_nav_master_latest.csv

Raw text/csv - it opens in a browser or Excel, and pd.read_csv works straight off the URL with no unzipping. Also latest.csv.gz, latest.csv.zip and latest.parquet (latest.csv is the same file as bare latest). The 23 columns cover identity (scheme code, both ISINs, name, AMC, TXIC code), classification (type, category, sub-category, group, plan, option), lifecycle (first and last NAV dates, active and stale flags), size (average AUM with its quarter label and ISO quarter-end), the NAV itself (date and value), and source last (MF or SIF). The exact column names and their per-column caveats are machine-readable in the API catalog under schema.latest_snapshot - read them there rather than from this page, so a column rename can never leave you working from a stale list.

Two grouping columns, and they answer different questions. category_group_clean is the analysis lens - a small, stable set (Equity / Debt / Hybrid / Other) that every raw name maps into deterministically, so a group-by is comparable across the whole history. category_group is the raw AMFI header as filed, which currently carries 20+ coexisting values because fund houses are still re-filing under SEBI's 2026 recategorisation. Use the clean one for reporting, the raw one when you want the mid-level detail or need to see exactly what AMFI filed. Note the clean set folded Solution Oriented and Fund of Funds into Other Scheme under the 2026 rules, so it is four values now rather than the six you may have seen earlier.

Two ISIN columns. isin is the payout or growth ISIN; isin2 is the reinvestment ISIN where one exists. They are sub-options of the same IDCW plan, not different funds - same scheme, same NAV row. Reinvestment ISINs resolve for all active schemes and most matured ones (about 7,000 mappings), so an ISIN lookup succeeds whichever of the two a client happens to hold.

import pandas as pd
df = pd.read_csv("https://api.tigzig.com/mf/v1/download/amfi_nav_master_latest.csv")
live = df[df.is_active]                        # the ~8,600 schemes still publishing
big  = live.nlargest(20, "aaum_cr_quarterly_avg")            # largest by average AUM

Three things to know before you trust a number from this file. Each one produces a wrong answer silently rather than an error.

1. It is each scheme's most recent NAV, not today's NAV for every row. Every scheme is included, matured ones too, so a fund that wound up in 2008 sits there with its final 2008 NAV. About 8,600 rows are live; the other ~29,000 are closed schemes frozen at their last NAV, and roughly 2,300 of those carry a final NAV of exactly 0.00 - AMFI's own closing entry, kept as filed. Read a 0.00 on an inactive row as end of life rather than a price, and exclude those rows before you average anything. Filter is_active, read nav_date. Deliberate - it keeps the file survivorship-bias-free, like the full dataset.

2. One scheme code is one plan-and-option variant, not a fund. To size a fund you sum its family. Aditya Birla Sun Life Value Fund is four codes - 5,628 + 705 + 68 + 11 = about 6,412 Cr. Quote any single row and you understate the fund, in that case by nine tenths. Note also that the oldest code in a family often carries plan Other, because it predates the 2013 Direct/Regular split.

3. Sort quarters on aaum_quarter_end, never on aaum_quarter. The label is text, so alphabetically December-2025 < June-2026 < March-2026, which is not chronological. aaum_quarter_end is the ISO twin (2025-12-31, 2026-03-31, 2026-06-30) and sorts correctly.

On AUM specifically: aaum_cr_quarterly_avg is the average of daily net assets over the quarter, per SEBI's definition - not a month-end or quarter-end balance - so a scheme launched mid-quarter reads low against a full-quarter peer. It is populated for about 8,400 rows (live schemes with a disclosed quarter); matured schemes have it blank. Renamed from aaum_cr on 2026-08-12 (manifest schema_version 2) because the old name read like a point-in-time AUM. Same values, same units, same position - if your code does df['aaum_cr'] it will raise a KeyError, so rename the reference and nothing else changes. The per-column definitions, including this one, are machine-readable in the API catalog under schema.latest_snapshot.column_notes - that is the canonical home, so an agent gets the caveats without reading this page.

Instead of looping over 38,000 schemes, grab everything at once - a single pre-generated file for all 37M+ rows, served via Cloudflare R2 (free egress, edge-cached):

GET https://api.tigzig.com/mf/v1/download/amfi_nav_master.parquet

Seven format values (default parquet): parquet (~170 MB), csv.gz / csv.zip / tsv.gz / tsv.zip (~235 MB), sqlite.gz / sqlite.zip (~1.3 GB). Bare sqlite is an alias for sqlite.gz. The SQLite file unpacks to about 5.5 GB, so allow about 7 GB free. Its nav is a binary float, so round to 4 places; the Parquet file is exact. Load straight into pandas:

import pandas as pd
df = pd.read_parquet("https://api.tigzig.com/mf/v1/download/amfi_nav_master.parquet")
print(df.shape)   # every scheme, every day
df["nav"] = df["nav"].astype(float)   # parquet stores nav as DECIMAL - see note below

SIF are in the same files. Specialized Investment Funds (SIF) sit below the mutual funds in every NAV file, full history and snapshot. The last column, source, says which: MF or SIF. Filter on source = 'MF' (or 'SIF') before totals across schemes. A category filter alone does not separate them, because SIF uses the same category groups. A SIF scheme_code is the number in AMFI's SIF code (SIF-120 is 120); every mutual fund code is 100027 or above.

One parquet quirk worth knowing before it bites. In the parquet downloads (both the full history and the snapshot) nav is a DECIMAL logical type, so pandas hands you Python Decimal objects rather than floats. Aggregations like .mean() still work, which is what makes this easy to miss - but arithmetic against a float, df.nav * 1.05, raises TypeError: unsupported operand type(s). Cast once on load, as above. The CSV and TSV downloads give you plain floats and need no cast, and note it is nav specifically - aaum_cr_quarterly_avg already comes through as a float. The decimal type is deliberate: it preserves AMFI's filed precision exactly rather than rounding it into a float.

Authoritative per-file list (formats, exact sizes, row count, last-refresh time): GET /mf/v1/downloads/manifest. It also reports a validation block confirming the generated files match the source row count, and a sources block with the rows for MF and for SIF. The manifest supports If-None-Match for cheap daily re-polls (returns 304 Not Modified when unchanged) - poll the manifest, and only re-download a file when the manifest says it changed. The download files themselves now honour conditional requests too: every 200 carries Content-Length, ETag and Last-Modified, and sending If-None-Match or If-Modified-Since returns 304 Not Modified with no body. So the cheap daily loop is: fetch once, keep the ETag, re-poll conditionally, and only receive bytes on the days the file actually changed.

File-name addresses. Every file also has an address that ends in its own file name, for example https://api.tigzig.com/mf/v1/download/amfi_nav_master.parquet. curl -O and wget save it under the right name. The ?format= form keeps working. Every file's address: https://api.tigzig.com/downloads/mf.

Query a parquet file in place. Parquet files support HTTP range requests, so DuckDB, pyarrow, polars or a browser can query them in place and read only the parts a query needs. For browsers, responses expose Content-Range, Content-Length and ETag to cross-origin JavaScript.

SELECT count(*) FROM read_parquet('https://api.tigzig.com/mf/v1/download/amfi_nav_master.parquet');

One row per scheme with what the MFPRO Fund page shows. It covers AMFI's daily fund size for all plans, the riskometers and benchmark, the scheme summary document (fund managers, launch and NFO dates, filed benchmarks, objective, exit load, SIP and redemption terms) and the latest expense ratio for the Regular and Direct plans. About 11,400 rows and 61 columns, 1.3 MB as parquet.

GET https://api.tigzig.com/mf/v1/download/scheme_details_latest.parquet
GET https://api.tigzig.com/mf/v1/download/scheme_details_latest.csv.gz

For one scheme or a short list, the same values come back as JSON. Codes and ISINs both work, up to 50 per call:

GET https://api.tigzig.com/mf/v1/schemes/118989/details
GET https://api.tigzig.com/mf/v1/details?schemes=118989,120503,INF179K01XQ0

SIF. Both details calls also take SIF codes and SIF ISINs, and each SIF item has source and sif_code. The scheme_details_latest download has SIF rows after the mutual funds, with source as the last column. The data quality file covers mutual funds only; SIF's open issues are on sif.tigzig.com. SIF has no daily fund AUM, because AMFI's daily AUM feed does not include SIF, so amfi_daily is empty on every SIF reply. The quarterly average AUM is filled for mutual funds and for most SIF schemes.

Both replies wrap the result in data, which /nav does not. For one scheme, data is an object. For a list, data is an array, next to count, not_found (codes we do not recognise) and no_details (real schemes with no details row). Inside each scheme, the amfi_daily, ssd and ter groups can each be null. About a quarter of schemes have no TER filing, so check for ter: null before you read from it.

Joining to NAV. Scheme details has one row per scheme_code. NAV has one row per scheme per date. Join the two on scheme_code.

Fund size repeats on every plan. The columns that start with amfi_daily_, ssd_ and ter_ describe the whole fund, so each plan's row carries the same value. To total fund size, add up amfi_daily_fund_aum_cr_all_plans only on rows where fund_dedup_flag is true. A fund has four plans on average, so summing every row overstates the total about four times. The column definitions are in the MFPRO data dictionary.

A second file lists the rows that could not be matched cleanly between AMFI's daily feed and the scheme documents, with the reason for each: GET /mf/v1/download/data_quality.csv (or json). Row counts, sizes and source dates for both files are in the manifest under datasets.

Every error is a JSON body you can act on in code. Switch on the top-level code. It is always present and always an UPPERCASE string, for example NOT_FOUND, INVALID_DATE_FORMAT or UNRECOGNIZED_PARAMETER. A real reply for an unknown scheme:

{ "code": "NOT_FOUND", "path": "/mf/v1/nav", "detail": "No NAV data found for identifier 999999.",
  "error": { "code": "NOT_FOUND", "message": "...", "docs_url": "https://api.tigzig.com/mf/v1/docs",
             "hint": "... https://api.tigzig.com/mf/v1/search?q=<fund name>" },
  "help": { "catalog": "https://api.tigzig.com/mf/v1/", "docs": "https://www.tigzig.com/apis/mf-nav" } }

Most MF errors carry error as an object like the one above. The shared replies for an unknown path (404), a wrong method (405) and the rate limit (429) carry error as a short lowercase label instead, next to the same top-level code. So read code and the shape of error stops mattering. The help block points at this API's machine catalog and docs page. A 429 also carries reason, retry_after_seconds and a Retry-After header. One exception for now: a download 400 for an invalid format has no top-level code yet, so read error.code there. The full list of codes is under error_shape.known_codes in the machine catalog.

A 404 for an unknown scheme also carries an error.hint pointing you straight to /mf/v1/search to resolve a fund name to its code - so an agent can self-correct from the first failed response instead of guessing identifiers. Likewise, calling /nav with a category= or amc= filter (a natural guess) returns a 400 that points you to the browse filters on /search, and tells you to call /nav with the codes you picked.

If the identifier is a corrupted ISIN - it fails the ISIN check-digit test (the 12th character is arithmetic over the first eleven) - the 404 says exactly that and tells you retrying will not help, so you fix it at the source rather than loop. A well-formed ISIN that simply is not in AMFI's data still gets the search-by-name hint. You do not need to run your own validator; the API does the arithmetic and tells you which case you are in.

The canonical names above are all you need - scheme, schemes, since, to, q, and the paths in steps 1-4. For convenience the API also accepts a few aliases (handy if you are porting from another naming convention; you never have to use them, and they are intentionally kept out of the OpenAPI spec and the machine catalog):

• Param synonyms on the NAV endpoints: scheme_code for scheme; from, start, start_date for since; end, end_date, until for to.
• On /search: name and query for q (e.g. /mf/v1/search?name=axis focused).
• Paths that route to GET /mf/v1/nav: /mf/v1/nav-history, /mf/v1/history, /mf/v1/nav/history, /mf/v1/series.
• Paths that route to the canonical /mf/v1/schemes/{code}/nav: /mf/v1/nav/{code}, /mf/v1/schemes/{code}, /mf/v1/scheme/{code}, /mf/v1/history/{code}, /mf/v1/schemes/{code}/history, /mf/v1/series/{code} (the singular /mf/v1/scheme/{code}/nav works too).