Bulk Stock Data Download vs API: Which to Use
September 8, 2026
A bulk download hands over whole files and leaves the filtering to whoever downloaded them. An API returns only the rows that were asked for. For work that covers a defined slice of the market, meaning a few hundred tickers, daily bars or quarterly statements, and a fixed window, the API path costs less time and far less pipeline maintenance. Bulk files earn their keep in the opposite case: every trade and every quote across the whole market, or a pipeline that has to run offline against a frozen local copy.
The size of the dataset is not what decides this. The shape of the question is.
What does a bulk stock data download actually give you?
Massive, which traded as Polygon.io until an announced rename in October 2025 (massive.com/blog, checked 8 September 2026), publishes flat files over an S3-compatible endpoint. For US stocks the datasets are day aggregates, minute aggregates, quotes, and trades, described in its own documentation as candlesticks at per-day and per-minute granularity, top-of-book quotes with nanosecond timestamps, and tick-level trade data (massive.com/docs, checked 8 September 2026). The files are gzip-compressed CSV, one per trading day, laid out by dataset and date. Massive’s own walkthrough lists and copies them with the MinIO client, using paths of the form flatfiles/us_stocks_sip/day_aggs_v1/2024/03/2024-03-04.csv.gz (massive.com/blog, checked 8 September 2026). Flat files sit behind a subscription: the pricing page lists them from the Starter plan at $29 a month, while the free Basic tier is capped at 5 API calls a minute with two years of history (massive.com/pricing, checked 8 September 2026).
The SEC publishes bulk archives of its own, free of charge. The Financial Statement Data Sets carry the numeric facts from the face financial statements of XBRL filings, distributed as ZIP archives of tab-delimited files and, in the agency’s words, "updated quarterly", with data filed after the last business day of a quarter appearing in the following quarterly posting. Archives run from 2009, and the most recent one listed on 8 September 2026 was 2026 Q2 (sec.gov, Financial Statement Data Sets). EDGAR separately publishes companyfacts.zip, which holds all the data behind the XBRL company facts and frames APIs, and submissions.zip, which holds the public filing history for every filer. Both are recompiled nightly at approximately 3:00 a.m. Eastern (sec.gov, EDGAR application programming interfaces).
Those are real products, well documented, and in the SEC’s case free. What they have in common is that the unit of delivery is a file covering a period, not an answer covering a question.
What does an API give you that a file does not?
Filtering before transfer is the obvious difference and the least interesting one. The difference that changes results is identity.
A flat file names a security by the ticker it carried on the day the file was written. Nothing inside the file records that FB and META are the same company, that the GM trading before 2009 and the GM trading after it are not, or that DELL disappeared from the market in 2013 and came back in 2018 under the same four letters. Any study that joins files across years on the ticker column inherits every one of those breaks silently. Rebuilding the identity layer is a research project in itself, and it is the part of the work that a file format cannot help with.
An API can carry that layer in the response. xfl.resolve("GM") returns the entity history behind the symbol, and every row of every xfinlink endpoint carries an entity_id that survives ticker changes, so joins between prices, statements, and metrics do not depend on the symbol being stable. Index membership works the same way: xfl.index("sp500", as_of="2015-06-30") returns the roster as it stood on that date rather than today’s roster read backwards, which is the difference between a clean historical sample and one filtered by survival. The full parameter list is in the docs.
Bulk files vs an API, side by side
| Bulk files | API | |
|---|---|---|
| What arrives | Every ticker for the period the file covers | Only rows matching the ticker, field, and date filters |
| Setup | S3 client or download script, decompress, load into a store, track publisher schema changes | pip install xfinlink, one function call |
| Local storage | Grows with market coverage, not with the question | None beyond the DataFrame |
| Freshness | As of the file’s publication, quarterly for the SEC statement sets | As of the last update behind the endpoint |
| Finest granularity | Trades and quotes with nanosecond timestamps (Massive) | Daily bars, aggregated server-side up to yearly |
| Cross-dataset joins | Written and maintained by the caller | Server-side; prices, statements, and metrics share entity ids |
| Identity across ticker changes | Not in the file | resolve() and entity_id |
| Practical ceiling | Bandwidth and disk | Plan limits on rows and requests per day |
How much data does the work actually need?
Take a plain research request: one year of daily closes for ten large caps.
import time
import xfinlink as xfl
xfl.set_api_key("YOUR_API_KEY") # free at https://xfinlink.com/signup
tickers = ["AAPL", "MSFT", "JNJ", "XOM", "JPM", "PG", "CAT", "KO", "UNH", "HON"]
t0 = time.time()
df = xfl.prices(tickers, start="2025-09-08", end="2026-09-04", fields=["close"])
elapsed = time.time() - t0
print(f"rows: {len(df)} tickers: {df['ticker'].nunique()} seconds: {elapsed:.1f}")
print(f"memory: {df.memory_usage(deep=True).sum() / 1024:.0f} KB")rows: 2510 tickers: 10 seconds: 5.4
memory: 560 KBTen tickers, 251 sessions each, 560 KB in memory, one call, no local store and no schema to maintain. The same window taken as day-aggregate flat files is 251 separate daily files, each holding a row for every ticker that traded that session, which then have to be decompressed, concatenated, and filtered down to the ten names the question was about. The arithmetic favours files only when the ten names become several thousand and the window becomes a decade, and even then the deciding factor is usually whether the analysis needs intraday detail that a daily bar cannot express.
Throughput matters here too. Plan limits govern how much an API will hand over in a day, and it is worth sizing that against the job before subscribing; our guide to financial data API rate limits works through the numbers.
When is a bulk file the right call?
Tick-level work, without argument. Questions about spreads, order flow, or execution quality need every print, and a request-and-response API is the wrong shape for that: Massive publishes trades and quotes in exactly the form those questions require. A local file is also the stronger choice when a result must stay reproducible years later, because a file sitting on a disk cannot be revised underneath the analysis that used it.
Neither requirement describes most equity research, where the sample is a few hundred names, the frequency is daily or quarterly, and the expensive part of the project is the joining rather than the downloading.
Which should you pick?
Ask what the smallest correct answer to the question looks like. If it is a table of a few thousand rows spanning named companies and a known window, requesting exactly that table is the shorter path, and it stays short as the study grows because the filtering happens on the server. If it is the whole tape at nanosecond resolution, take the files.
For everything in the first category, xfinlink returns prices, financial statements, computed metrics, index membership, and entity history through one Python client, joined on stable entity ids rather than on tickers. The free tier covers 100 requests a day across a rolling one-year window with one ticker per call, and paid plans open the full history, with daily prices back to 1996 and fundamentals back to 1950. Details are on the pricing page. If the alternative under consideration is parsing pages rather than downloading files, the failure modes differ again, and we covered those in web scraping vs a financial data API.
FAQ
Is a bulk download cheaper than an API?
The subscription is rarely the deciding cost. The recurring cost of a file pipeline is engineering time: storage, load jobs, deduplication, and keeping a local schema in step with the publisher’s.
How stale is a quarterly bulk file?
The SEC states that its Financial Statement Data Sets are updated quarterly and that documents filed after the last business day of a quarter appear in the following quarterly posting (sec.gov, checked 8 September 2026). A 10-Q filed in July is therefore not in a file dated to the second quarter.
Can flat files tell me which stocks were in the S&P 500 in 2015?
No. A day-aggregate file records prices and volume per ticker for one session; index membership is a separate dataset entirely, and reconstructing a past roster from price files is not possible. xfl.index("sp500", as_of="2015-06-30") returns it directly.
Built with xfinlink — free financial data API for Python. pip install -U xfinlink
pip install -U xfinlink