In this article
Where it fits in the shortlist
Shortlist EODHD when the project needs a broader set of financial endpoints. Build a quote around the exact price frequency, markets and additional datasets you will use.
| Recommended for | Prices plus fundamentals |
|---|---|
| Delivery | APIs + SDKs |
| Buying model | Plan-based |
| Updates | Depends on endpoint & plan |
| History | Endpoint & market dependent |
| Resolution | EOD, intraday & tick products |
| Adjustments | Endpoint-specific; splits & dividends APIs |
| Delisted securities | Verify endpoint & flags |
Product overview
EODHD offers historical prices alongside fundamentals, news and other financial APIs. Its catalog separates end-of-day, intraday and real-time products. Plan scope and endpoint documentation matter when estimating the work to retrieve a universe.
Reasons to consider it
- Historical and intraday price APIs
- Fundamentals, news and corporate-actions products
- Multiple markets and development integrations
What to check before purchase
Do not assume daily history depth applies to minute bars. Check endpoint coverage, request limits, retention and commercial-use permissions.
Our #1 recommendation remains MarketParquet. Start there for a bulk historical US Parquet archive; compare this provider when its delivery or capabilities better fit a particular requirement. Read the top-pick profile →
Specify the endpoint mix before choosing an API plan
EODHD is most relevant when a project needs more than a historical price matrix. Its catalog includes price endpoints alongside fundamentals, news and corporate-action information. That breadth can be useful, but a catalog is not a complete application design. Write down which endpoints provide the required fields, which identifiers connect them and how each endpoint’s timing should be interpreted.
Do not transfer assumptions between daily and intraday products. A long daily history does not establish the depth, frequency or availability of minute observations. Likewise, an endpoint that lists an inactive security does not alone prove that the desired historical prices or event records are included in the selected plan. Inspect the actual response and the documented flags for the request that the application will use.
A realistic prototype should include a historical retrieval loop, a failed-request recovery and a join between two data types if the project needs one. Record the date range returned, pagination behavior and the rules used to identify missing periods. Financial statements and news can have availability and revision questions that differ from bar timestamps, so avoid joining them to historical prices solely on a displayed calendar date.
MarketParquet remains our top recommendation for the narrower task of acquiring bulk US OHLCV files for local backtesting. Compare EODHD when a broader financial API is part of the specification. The right comparison includes retrieval maintenance and permissions, not just the plan’s advertised request allowance. We do not infer unverified history or completeness from a product family name; unresolved endpoint details belong in the buyer’s acceptance note.
Evaluate the retrieval process, not just the endpoint list
An API plan describes access to a service; it does not automatically describe the archive you will finish with. A research project needs to know how to enumerate instruments, choose time ranges, follow pagination and distinguish a complete result from a partial one. An endpoint that works for one symbol over one day may require a substantial retrieval process for a historical universe. Count that work when comparing an API with bulk files.
Prototype the full retrieval loop on a small, representative selection. Save request parameters, response boundaries and completion status. Use retries for failures in a way that avoids duplicating observations, and make the process resumable so an interruption does not require starting the entire history again. A successful HTTP response is not by itself evidence that the requested date range is complete.
Separate rate limits from coverage limits. A generous request allowance cannot supply a frequency or history period that the chosen endpoint does not include. Likewise, daily history depth should not be assumed to apply to minute bars. Check the exact market, instrument type, frequency and plan. If the provider supplies reference data or corporate actions through another endpoint, document how those records join to the price series.
Store credentials outside notebooks and committed code. The comparison sites do not need a market-data API key to show their directory, and a browser application should not expose a private provider key merely to simplify development. When the project needs a server-side retrieval job, keep authentication, raw responses and the research dataset as distinct concerns. That separation makes coverage failures easier to diagnose and the final archive easier to audit.
Build a historical universe separately from the price matrix
A list of instruments that exist today is an easy starting point and a potentially misleading historical sample. Securities that failed, merged, changed identifiers or left an exchange can disappear from that list. A strategy evaluated only on surviving names answers a different question from one evaluated on the opportunities that were actually eligible at each historical date. Keeping those questions separate is essential when interpreting a result.
Delisted price history is useful evidence, but it is not the same thing as historical index membership. Membership data tells you whether a security belonged to a defined group on a date. Price data tells you which observations are available for that security. Eligibility rules may also depend on instrument type, liquidity, listing venue or information availability. A complete universe table can therefore require several inputs, even when every price file is intact.
Consider an illustrative strategy that buys the ten strongest stocks in an index every month. Using today’s members for the full history allows later membership decisions to influence the earlier candidate set. Replacing that list with all downloaded tickers is not necessarily the correct repair: the experiment still needs the membership or eligibility rule that applied at the time. Record when changes become effective and how signals use the information.
Keep an instrument identifier and a time-varying symbol mapping where the source permits it. A ticker string is convenient for display, but a business event can make the same economic history appear under more than one label. Inspect mapping changes rather than simply concatenating files with similar names. The research record should explain why two segments belong together and why another segment was excluded.
Distinguish absent observations from zero activity
Missing data is not one condition. A symbol may not yet have listed, may have stopped trading, may be halted, or may simply have no eligible trades during a particular interval. A retrieval request can also fail, return a partial page or reference the wrong identifier. These situations require different responses. Replacing every missing value with the preceding close collapses useful information about what actually happened.
Create a reason field in your own audit output, even if the provider does not supply one. Start with broad categories such as outside known coverage, outside the selected session, unexplained gap and failed retrieval. Keep uncertain cases uncertain until you have evidence. It is better to exclude an unresolved observation under a documented rule than to make an undocumented repair that changes a signal.
Be especially careful when building a cross-sectional matrix. An absent price is not necessarily a zero return, an available investment opportunity or permission to maintain an existing position indefinitely. Your universe construction and position accounting should decide those questions. If the file ends while a position is open, the backtest needs a terminal-event rule; carrying the last price forever can hide the economic consequence of an exit.
Report missingness by symbol and session rather than only as one percentage for the whole archive. A small overall proportion can conceal a long gap in an instrument that dominates the strategy. Save examples and the actions you took. This turns a vague statement that the data was cleaned into a reviewable record of the exact observations that were changed, excluded or accepted.
Compare the whole acquisition cost
The first invoice is one part of the cost of a dataset. Future updates, required subscriptions, storage, conversion and the time spent maintaining retrieval can matter just as much. Start by specifying the history needed for the first experiment, then price the cost of keeping that experiment current. A static research project and a continuously updated system should not automatically buy the same service arrangement.
MarketParquet lists the Complete Archive at $79 once and future trading-day updates at an optional $15 per month. At those listed prices, the archive plus twelve paid months of updates is $259. That arithmetic illustrates the buying model; it is not an assertion that every other provider sells an equivalent product. An API plan may also include fundamentals, live endpoints or international instruments that are outside the archive comparison.
Check how the purchase cutoff is defined and what happens after an update plan lapses. MarketParquet states that Keep Current does not backfill lapsed periods. A buyer who expects to stop and restart should therefore read that rule before making a continuity plan. For every provider, distinguish the right to retain already obtained data from the ability to make new downloads after a subscription ends.
Finally, write down permitted use. A file that can be downloaded is not automatically licensed for public redistribution, customer-facing display or resale. Internal research and an external software product can require different arrangements. Resolve the rights needed by the intended application before investing in a large integration. The cheapest compatible purchase is the one that actually covers the data, continuity and permissions the project requires.
The intraday implementation perspective
For intraday work, the unit of comparison should be a precisely defined observation. Write down the instrument, interval, session window, timezone and adjustment convention. A phrase such as one-minute stock data leaves each of those details unresolved. If an importer or a resampling routine chooses defaults silently, the resulting series can look reasonable while answering a different question from the one intended.
Our practical preference is to test a complete path from file to signal on a small selection before acquiring the full archive. Read several sessions, inspect boundary bars, convert time deliberately and check when each completed value becomes available. Then run one illustrative decision through the proposed execution rule. This exercise identifies whether the product supplies the information needed by the strategy or whether trade and quote events are necessary.
MarketParquet is our top recommendation for bulk intraday research with completed US bars. Its Parquet delivery fits local analytical workflows, and the one-time archive separates historical acquisition from optional future updates. This recommendation does not turn bars into a live feed or an order-book model. Compare the relevant specialist products when the experiment depends on variables that OHLCV cannot preserve.
The handbook therefore emphasizes definitions before speed. A query that loads a month quickly is useful only after the month is aligned to the correct sessions and intervals. Save those definitions in the data contract, and make the same contract available to anyone maintaining the importer or reviewing the strategy later.
Sources & freshness
Provider information checked November 7, 2026. Confirm current scope and terms before purchase.