ETF Holdings Data API vs CSV Feeds

An ETF holdings data API is an HTTP endpoint that returns the constituent securities of a given ETF or index, with weights, share counts and identifiers, for a requested ticker and date. That definition is where almost every vendor page on this topic starts and stops. It is also the least interesting part of the decision, because the endpoint shape is nearly identical across providers while the data quality behind it is not.

The questions that actually determine whether a holdings feed survives contact with production are different: how stale the underlying disclosure is regardless of how fast the API responds, whether the identifiers in the payload join cleanly to your security master, what the file does on rebalance and corporate action dates, how far back point-in-time history goes, and whether a REST call or a scheduled bulk file is the right delivery mechanism for the job you are doing. Delivery mechanism and data quality are separate decisions. Most comparison content collapses them into one.

What is an ETF holdings data API?

An ETF holdings data API is an HTTP endpoint that accepts a fund ticker and returns that fund's constituent list: each holding's name, an identifier, a weight, and usually a share or par quantity, along with an as-of date. Most implementations are REST, return JSON, and are paginated for funds with large constituent counts.

A typical response payload carries some subset of the following fields per holding:

• Security name and, in most cases, a local exchange ticker
• One or more identifiers: CUSIP, ISIN, SEDOL, or an open identifier such as a Bloomberg FIGI
• Weight in the fund, usually as a percentage of net assets
• Share count or par value held
• Market value of the position
• Asset class, sector, and country classification, where the vendor adds it
• An as-of or effective date describing when the holdings were struck

Fund-level fields usually sit alongside the constituent array: total net assets, constituent count, expense ratio, and sometimes leverage factor and a fund description.

Field names, coverage universes and update cadence differ between providers, and no vendor's current documentation was read in preparing this article. Treat any field list, including this one, as a starting point for your own read of a vendor's live documentation rather than a specification of what any named product returns.

The important observation is that a payload description tells you nothing about whether the numbers in it are current, correctly identified, or reproducible six months from now. Those are the properties that break pipelines.

How do I see all holdings of an ETF?

There are three routes to a complete ETF constituent list: the issuer's own daily holdings file, regulatory filings with the SEC, and a commercial data service that normalises both. Each route trades engineering time against coverage and consistency.

Issuer disclosure. Transparent US equity ETFs publish a daily holdings file on the sponsor's website, typically as CSV or XLSX, updated each business day. This is the authoritative source and it is free. It is also the route that scales worst: file layouts, column names, date formats, header rows, encoding, and the URL pattern itself all differ by issuer, and they change without notice.

Regulatory filings. Registered funds file portfolio holdings with the SEC on Form N-PORT, and schedules of investments appear in annual and semi-annual shareholder reports. The reporting and public-availability cadence for N-PORT has been amended in recent years, so check the current rule text at the SEC rather than a vendor's summary of it. Filings are structured and auditable, but they lag daily disclosure by construction and are not a substitute for a current constituent list.

Commercial data services. A holdings vendor absorbs the parsing, normalisation, identifier mapping and change detection, and delivers one schema across the universe. What you are paying for is not access to the numbers, which are public, but the elimination of several thousand small breakages a year.

The scale argument is worth being concrete about. Maintaining scrapers for a hundred funds is a weekend project. Maintaining them across a universe in the thousands, spanning dozens of issuers and multiple domiciles, means a standing engineering commitment measured in person-months per year, with a failure mode where one issuer's silent column rename corrupts your sector weights and nobody notices for a week. If you are constructing sector exposure from constituent data, that failure is invisible until the aggregates are wrong, which is why the mechanics of ETF classification by sector deserve as much attention as the feed itself.

Why API freshness is not the same as holdings freshness

A real-time API call can return a stale holdings file. Response latency is a property of the vendor's infrastructure; holdings currency is a property of the fund's disclosure regime, and no vendor can deliver constituent data that the issuer has not published.

Transparent equity ETFs publish a full portfolio daily, so a well-run feed can be one business day current. Other structures cannot be. Semi-transparent and non-transparent active ETFs disclose on a delayed or proxy basis by design, which is the point of the wrapper. Mutual funds disclose on regulatory cadence, which means the "latest" holdings for a given fund may be weeks or months old regardless of how quickly the endpoint answers.

This is where "real-time ETF holdings API" in marketing copy is doing work it cannot support. The call is real-time. The holdings are as fresh as the last disclosure.

How to detect staleness in a payload

Read the as-of date, not the response timestamp. A payload that returns only a retrieval time and no effective date for the holdings themselves is unusable for anything with a compliance trail, because you cannot later prove what you knew and when you knew it.

Three checks worth building into ingestion:

1. As-of date drift. Alert when the effective date on any fund has not advanced for more than a set number of business days, with per-structure thresholds so non-transparent funds do not spam the alert channel.
2. Share count reconciliation. Large creation or redemption activity should move share counts across the whole basket proportionally. A basket where share counts are frozen while shares outstanding moved is a stale file wearing a fresh date.
3. Constituent count deltas. A sudden drop in constituent count is more often a truncated file than a portfolio change.

Cadence you can schedule against matters more than cadence that sounds fast. AmericanETP updates constituent lists twice daily, with the primary run at 6pm EST and a secondary run around noon EST, which means a downstream job can be pinned to a known window rather than polling and hoping. Around the clock trading has made that window question sharper for anyone whose systems now run past the US close, a problem covered in what 24×5 trading breaks in data pipelines.

Identifiers: the field that decides whether the feed is usable

The identifier field determines whether a holdings feed is an asset or a project. A payload that returns only a security name and a local ticker will cost you more in mapping work than the subscription saved, because the join to the rest of your stack has to be reconstructed by hand.

Local tickers are ambiguous across three axes at once. The same ticker resolves to different securities on different exchanges. Cross-listed shares carry different local tickers for the same economic claim. Multiple share classes of the same issuer differ by a suffix convention that is not standardised across data sources. Any one of these produces a silent mismatch rather than an error.

The licensed identifiers, CUSIP, ISIN and SEDOL, solve the ambiguity but come with their own friction: redistribution terms, per-user licensing, and the awkward situation where a vendor cannot pass through an identifier you already license separately.

Bloomberg FIGIs sit differently. As an open standard, the FIGI can be carried through a holdings file without the licensing negotiation that surrounds proprietary identifier sets, which makes it a practical join key between constituent lists, position files, reference data and pricing. AmericanETP includes FIGIs in constituent list holdings files, and documents the related mappings under its Bloomberg extensions.

What to test during an evaluation

Do not evaluate identifier quality by reading the field list. Take a real sample and measure.

Pull constituent files for fifty funds spanning US large cap, US small cap, developed international, emerging markets and fixed income. Join each against your own security master on every identifier the payload provides. Record the unmatched rate per identifier type and per asset class. Small cap and emerging market equity, plus anything in fixed income, is where mapping quality separates vendors; a feed that matches at 99.9 percent on S&P 500 constituents and 92 percent on emerging market small caps has told you something the sales deck did not.

API endpoint or bulk CSV feed: which delivery shape fits the job

Delivery shape is an engineering decision about access patterns, not a quality decision. A per-ticker REST endpoint and a scheduled bulk constituent file can carry identical data, and the right choice depends entirely on whether your access pattern is sparse and interactive or dense and batch.

The arithmetic on a full-universe refresh is worth doing before you sign, with your own numbers rather than anyone else's. Multiply the count of funds in your universe by their average constituent count, divide by the page size the vendor's documentation specifies to get a call count, then divide by their documented rate limit to get wall-clock time. Add retry logic, partial-failure detection and reconciliation on top of that figure. The same snapshot delivered as a bulk file is one transfer and one checksum.

An API genuinely wins when access is sparse and driven by user action: a client portal where an advisor opens one fund's holdings on demand, a research tool with an interactive lookup, an internal service answering ad hoc questions. Fetching the whole universe nightly to serve twenty lookups a day is the wrong shape.

Bulk files win for nightly full-universe loads, research pipelines, backtests, and compliance archives where the file itself is the evidence. AmericanETP provides FTP access to constituent list files and publishes what is available through its downloads area, which suits the batch pattern directly.

Coverage, history and the questions to ask any ETF data vendor

Coverage and history are the two dimensions that are hardest to fix after you have built on a feed, because both determine what questions you can ask at all. A current-only feed cannot be retrofitted into a point-in-time archive.

Ask every vendor the same list:

• Index constituents as well as ETF holdings? Benchmark construction, tracking difference analysis and index-level aggregates need the index membership, not just the fund's replication of it.
• US-listed only, or global? Confirm which domiciles and listing venues are in scope, and how non-US funds are identified.
• Delisted, merged and terminated funds? A universe that silently drops closed funds produces survivorship bias in every backtest built on it.
• Point-in-time, or current snapshot only? Can you retrieve the constituent list as it stood on a specific past date, with the identifiers as they were then rather than as they are now?
• What is retained on rebalance days? Effective date, announcement date, and whether adds and drops are captured as events rather than inferred from file diffs.
• Fund-level attributes? Description, leverage factor and constituent count are what let you filter a universe before you process it.

AmericanETP covers 3,878 US and global indexes and US-traded ETFs, keeps archived constituent list datafiles back to July 2009, and publishes a fundamentals file carrying ETF description, leverage and constituent counts. Constituent additions and deletions are also surfaced separately through the constituent change report, which matters if your process needs the event rather than a diff you computed yourself.

Where the large platforms genuinely win

A dedicated constituent file service is not the right answer for every buyer, and pretending otherwise wastes your time. Large multi-dataset platforms sell breadth and entity linkage: holdings sitting alongside estimates, ownership, filings and pricing under a single entity hierarchy, so that one join answers a question that would otherwise cross four vendors.

If your workflow requires resolving a fund holding to an issuer, then to that issuer's subsidiaries, estimates history and credit data in one join, a standalone holdings feed will not get you there and integration work will not close the gap cheaply. No current documentation or pricing page from FactSet, Refinitiv, Morningstar or S&P Global Market Intelligence was read in preparing this article, so confirm which of them fits that description, and on what terms, from their own pages rather than from any summary including this one. The structural cost question is covered separately in the breakdown of what FactSet costs in 2026.

What holdings data costs, and how the pricing models differ

The structural difference in holdings data pricing is between metered API access, billed per call, per symbol or per tier, and flat subscription file access, billed per seat or per firm regardless of volume. The metered model penalises exactly the access pattern institutional users need, which is the daily full-universe refresh.

Under metered pricing, the cost of your pipeline scales with the size of your universe and the depth of your history, which means the marginal cost of asking a broader question is real and someone will eventually be asked to justify it. Research work that involves iterating over the full universe repeatedly is where this bites hardest, because the exploratory phase is the expensive one and it is also the phase where you do not yet know what you are looking for.

Flat subscription file access inverts that. The full universe costs the same as one fund, so the constraint moves from budget to storage and processing, both of which are cheap.

AmericanETP's pricing is confirmed at $1,500 per year or $150 per month for an individual, and $2,500 per year or $250 per month firm-wide. The firm-wide tier is the one that matters for the pattern above, because a per-seat model that scales with headcount reintroduces the same disincentive that metered API pricing does.

I am not stating competitor pricing here. Their pricing pages were not read today, published figures change without notice, and a stale number attributed to a named vendor is worse than no number. Check them directly, and where a vendor does not publish a per-seat or per-call figure at all, treat the absence as information about the sales process you are about to enter. The comparative framing for one such platform is set out in the FactSet pricing analysis.

Building on the feed: three workflows that depend on holdings data

Holdings data earns its cost in three institutional workflows: look-through exposure analysis, index-level aggregate fundamentals, and rebalance monitoring. Each one has a specific data requirement that a generic endpoint description does not address.

Look-through exposure and overlap

A book holding forty ETFs has an equity exposure profile that none of the forty fact sheets describes. Look-through means decomposing every fund to its constituents, summing weighted exposure by security, and finding where nominally diversified sleeves converge on the same twenty names.

The requirement here is identifier consistency, not freshness. If the same security arrives under two identifiers from two different funds, the overlap you calculate is understated, and understated overlap is the failure mode that concentration limits exist to prevent. Sector-level aggregation has the same dependency, which is why the sector classification mechanics sit upstream of the exposure report.

Index-level aggregate fundamentals

Weighted price-to-earnings, weighted book value and similar index aggregates are computed from constituent lists plus per-security fundamentals. The methodology choices, harmonic versus arithmetic weighting, trailing versus forward earnings, and the treatment of loss-making constituents, change the answer materially, which is why two credible sources publish different figures for the same index on the same day.

That divergence is examined in detail in why the reported P/E of the S&P 500 disagrees between sources, and the construction itself is walked through in building the P/E ratio for the S&P 500. The point for a data buyer is that you cannot audit an aggregate you did not compute, and you cannot compute it without the constituent list and weights.

Rebalance and reconstitution monitoring

On reconstitution dates, the useful field is the effective date, not the response time. A team tracking index changes needs to know which names enter and leave, when the change takes effect, and what the weights look like before and after, with enough lead time to plan execution.

An API that returns the current list quickly does not answer that question. A change file that names the adds, the drops and the effective date does. This is the case where the delivery-shape debate matters least and the content of the file matters most.

FAQ

How do I see all holdings of an ETF?

Three routes. The issuer publishes a daily holdings file on the fund's own page for transparent ETFs, which is free and authoritative but formatted inconsistently across sponsors. Registered funds file portfolio holdings with the SEC, which is auditable but lags daily disclosure. Commercial data services normalise both into one schema across thousands of funds, which is what you pay for once the universe is larger than a handful of funds.

Where can I get ETF data?

From the issuer directly, from SEC filings, or from a data vendor. Vendors split roughly into API-first providers oriented toward per-symbol lookups, bulk file providers oriented toward full-universe loads, and large platforms that bundle holdings with estimates, ownership and reference data. Choose on access pattern and identifier quality first, since delivery mechanism is easier to change later than a security master you built on ambiguous tickers.

Is there a mutual fund data API available?

Yes, several vendors offer mutual fund holdings alongside ETF holdings, but the disclosure cadence is the binding constraint. Mutual fund portfolio holdings are disclosed on regulatory cadence rather than daily, so the most recent available holdings for a mutual fund may be substantially older than for a transparent ETF, regardless of how current the API itself is. Always read the as-of date on the payload rather than assuming the retrieval date.

What is the 7% rule in ETF?

There is no 7 percent rule in US ETF regulation, index methodology or fund accounting. The phrase circulates informally and is usually either a reference to a long-run average annual equity return assumption or a personal stop-loss convention, neither of which is a standard. It is sometimes confused with genuine concentration constraints such as the UCITS diversification limits, which are specified in the relevant regulation and are not 7 percent.

Can I download daily ETF holdings as a CSV instead of using an API?

Yes. Bulk constituent files delivered on a schedule over FTP are the standard alternative to per-ticker REST calls, and they are the better shape when you refresh the full universe daily, run backtests, or need an archived file as compliance evidence. AmericanETP delivers constituent lists as files with FTP access and updates twice daily, at 6pm EST and around noon EST.

How far back does ETF holdings history usually go?

It varies widely, and many API-first providers return current holdings only, which introduces survivorship bias into any backtest built on them. Ask specifically whether the vendor holds point-in-time constituent files, whether delisted and terminated funds are retained, and what the earliest available date is. AmericanETP maintains archived constituent list datafiles back to July 2009.

If you are evaluating a holdings feed, test it on the two things that decide the outcome: the unmatched rate when constituent identifiers join to your own security master, and whether the as-of dates advance when you expect them to. AmericanETP has been publishing constituent data since the 1990s, originally as MasterDATA, and provides FTP access to daily constituent files, FIGIs in the holdings payload, and archives back to 2009. Review the data and delivery options, or get in touch with the specifics of your universe and access pattern.