Choose a Free Bitcoin Historical Data API
for Prices and OHLCV选择适合价格分析与回测的
免费比特币历史数据 API
Compare BTC price and candle APIs by intervals, history, free limits, and provenance—then request and validate Bitcoin data safely.
按 K线周期、历史范围、免费额度与来源比较比特币历史行情 API，
再安全请求并校验 BTC 价格与 OHLCV。
Free Bitcoin historical data API: quick answer免费比特币历史数据 API：快速结论
Timestamped open, high, low, close, and volume candles for a symbol, interval, and time range.
Free tiers differ in API keys, rate limits, historical depth, asset coverage, granularity, and commercial-use terms.
Check whether candles represent an exchange pair, an aggregate, or on-chain liquidity—and whether volume units are base or quote currency.
Choose the source that matches your market, interval, history, and refresh needs; normalize before charting or backtesting.
按交易对、周期和时间范围返回带时间戳的开、高、低、收与成交量 K线。
不同免费层在 API Key、频率限制、历史深度、币种覆盖、粒度与商用条款上差异明显。
数据究竟来自单一交易所、聚合市场还是链上流动性池，并确认成交量使用基础币还是计价币。
按市场、周期、历史范围与刷新需求选源，并在制图或回测前统一字段与时间戳。
What a Bitcoin historical data API can return比特币历史数据 API 可以返回哪些数据
“Bitcoin historical data” can mean a simple daily BTC/USD close, exchange-specific OHLCV candles, an aggregated reference price, market-cap history, or Bitcoin network metrics. These outputs are not interchangeable. Define the dataset before comparing free APIs so a convenient endpoint does not silently change the question you are trying to answer.
“比特币历史数据”可能指每日 BTC/USD 收盘价、某一交易所的 OHLCV K线、聚合参考价格、市值历史，或比特币网络指标。这些数据不能互相替代。比较免费 API 前应先定义数据集，避免因为某个端点调用方便而悄然改变原本要回答的问题。
Use a Bitcoin-specific regime checklist. Mark halving dates, major exchange closures, benchmark methodology changes, stablecoin dislocations, forks, prolonged network congestion, and the launch of important derivative or regulated spot markets. These events can change liquidity, price discovery, volume composition, or the relationship between BTC/USD and BTC/USDT. A backtest that spans several regimes should preserve the contemporaneous market structure rather than assume today’s venues and quote assets existed throughout the history.
应使用比特币专属的周期检查清单。标记历次减半、主要交易所关闭、基准方法变化、稳定币脱锚、分叉、长期网络拥堵，以及重要衍生品或受监管现货市场上线。这些事件会改变流动性、价格发现、成交量构成，以及 BTC/USD 与 BTC/USDT 的关系。跨越多个周期的回测应保留当时的市场结构，不能假设今天的场所和计价资产在全部历史期间都存在。
For long-horizon return series, document the daily cut-off, benchmark currency, weekend policy, and missing-source fallback. For event studies, keep intraday timestamps and avoid filling a venue outage with a composite price unless that substitution is part of the declared methodology. For joint market-and-network research, aggregate block metrics and prices independently before the time join so a late block or delayed market observation does not shift both series silently.
构建长期收益序列时，应说明每日截点、基准货币、周末规则和来源缺失时的回退方法。进行事件研究时，应保留盘中时间戳；除非方法明确规定，否则不要用综合价格填补某一场所故障。联合研究市场与网络数据时，应先分别聚合区块指标和价格，再按时间关联，避免迟到区块或延迟行情同时悄然移动两条序列。
Historical Bitcoin prices比特币历史价格序列
A price-history endpoint commonly returns timestamp and price pairs for a coin ID such as bitcoin, a quote currency such as USD, and a date range or number of days. This format is compact and useful for charts, returns, correlations, and portfolio reporting. Check whether the price is a provider aggregate, an index, or a specific exchange market.
历史价格端点通常根据 bitcoin 等币种 ID、USD 等计价货币，以及日期范围或天数返回时间戳与价格。它适合行情图、收益率、相关性和组合报告。需要确认该价格是供应商聚合价、指数价，还是某个具体交易所市场的成交价。
Bitcoin OHLCV and candle data比特币 OHLCV 与 K线数据
Candles add open, high, low, close, and volume for each interval. They are better suited to technical indicators and backtesting, but require an exact market definition: BTC/USD or BTC/USDT, venue, spot or derivative, interval boundary, volume unit, and whether the current candle is final.
K线按周期增加开盘价、最高价、最低价、收盘价与成交量，更适合技术指标和策略回测。但必须明确 BTC/USD 或 BTC/USDT、交易场所、现货或衍生品、周期边界、成交量单位，以及当前 K线是否已经结束。
Market cap, volume, and supply history市值、成交量与供应量历史
Some market-data APIs return price, market capitalization, and 24-hour volume in parallel arrays. These are useful for market reports but should not be confused with the traded volume inside one exchange candle. Supply fields may also differ by circulating, total, or maximum supply methodology.
部分行情 API 会并行返回价格、市值与 24 小时成交量，适合市场报告，但不能把它与某一交易所单根 K线内的实际成交量混为一谈。供应量字段也可能分别采用流通量、总量或最大供应量口径。
On-chain Bitcoin history is a separate dataset比特币链上历史属于另一类数据
Block height, transaction count, fees, hashrate, difficulty, UTXO statistics, and address activity come from blockchain or on-chain analytics sources. They may explain network conditions, but they do not replace market price candles. Keep market and network datasets separately identified when joining them by time.
区块高度、交易笔数、手续费、算力、难度、UTXO 统计和地址活动来自区块链或链上分析数据源。它们可以解释网络状态，但不能代替市场价格 K线。按时间关联两类数据时，应分别保留市场数据与网络数据的来源标识。
| Dataset数据集 | Typical fields常见字段 | Best suited to适合场景 | Key ambiguity关键歧义 |
|---|---|---|---|
| Price history价格历史 | timestamp, price | Charts, returns, reporting行情图、收益率、报告 | Aggregate or venue price聚合价或场所价格 |
| OHLCV | time, open, high, low, close, volume | Indicators and backtests指标与策略回测 | Market, boundary, volume unit市场、边界、成交量单位 |
| Market history市场历史 | price, market cap, 24h volume | Market research市场研究 | Provider methodology供应商计算方法 |
| On-chain history链上历史 | blocks, fees, hashrate, UTXO | Network analysis网络分析 | Indexing and metric definition索引与指标定义 |
What developers need from a Bitcoin historical price API开发者需要比特币历史行情 API 完成什么任务
Define the Bitcoin benchmark before requesting history请求历史前先定义比特币基准
This page is deliberately BTC-specific. State whether the research series is one exchange’s BTC/USD spot market, a BTC/USDT market, a regulated reference rate, a multi-venue index, or a derivative mark price. These series can diverge during exchange outages, stablecoin stress, regional dislocations, and thin weekend liquidity. A long Bitcoin chart needs one documented benchmark through time, not an unlabelled blend that changes when a venue disappears.
本页只聚焦 BTC。应明确研究序列来自某交易所 BTC/USD 现货、BTC/USDT 市场、受监管参考汇率、多场所指数，还是衍生品标记价格。交易所故障、稳定币压力、地区价差和周末流动性不足时，这些序列会明显分化。长期比特币图表需要一条方法稳定且有说明的基准，不能使用会随场所退出而变化的无标签混合价格。
Bitcoin price and Bitcoin network history answer different questions. Price series describe markets; block, fee, hashrate, difficulty, and UTXO series describe the protocol. Join them by explicit UTC timestamps and retain both source lineages.
比特币价格历史与网络历史回答不同问题。价格序列描述市场，区块、手续费、算力、难度和 UTXO 描述协议。关联两者时应使用明确 UTC 时间，并分别保留来源链。
Bitcoin history sources for regime analysis适合比特币周期研究的历史来源
Use it for executable-market research, basis studies, and venue incidents. Preserve quote currency, spot or derivative type, listing date, maintenance gaps, and the venue timezone.
适合可交易市场研究、基差分析和场所故障研究。应保存计价币、现货或衍生品类型、上市日期、维护缺口和场所时区。
Better for valuation and long-run reporting when methodology, contributor changes, outlier rules, and historical backfills are documented.
当指数方法、贡献场所变化、异常值规则和历史回补都有说明时，更适合估值与长期报告。
Use block height, issuance, fees, hashrate, and difficulty to study protocol conditions and halving regimes, not as substitutes for market OHLCV.
使用区块高度、发行量、手续费、算力和难度研究协议状态与减半周期，不能把它们当作市场 OHLCV 的替代品。
A versioned bulk file can preserve the exact dataset used by a study across exchange failures, benchmark revisions, and later provider repairs.
带版本的批量文件可固定研究实际使用的数据，即使之后发生交易所故障、基准修订或供应商修复，也能复现结果。
Understand the candle before comparing prices比较价格前先弄清一根 K线的定义
- Time boundary: determine whether the timestamp marks candle open or close and whether intervals align to UTC.
- Price basis: distinguish exchange trades, volume-weighted aggregates, index prices, mark prices, and DEX swap prices.
- Volume basis: identify base-asset volume, quote-currency volume, trade count, or provider-calculated volume.
- Incomplete candles: decide whether to exclude the current still-forming candle from indicators and backtests.
- 时间边界：确认时间戳代表 K线开始还是结束，以及周期是否按 UTC 对齐。
- 价格口径：区分交易所成交价、成交量加权聚合价、指数价格、标记价格和 DEX 兑换价格。
- 成交量口径：确认是基础币成交量、计价币成交额、成交笔数，还是供应商计算值。
- 未完成 K线：技术指标与回测通常应排除仍在形成的当前 K线。
Worked example: pagination boundaries and an unfinished candle实例：分页边界与未完成 K线
Assume a daily BTC/USD endpoint timestamps each candle at its 00:00 UTC open. Page one ends with the July 10 candle and page two begins with July 10 because both request boundaries are inclusive. Concatenating the pages without a key such as market + interval + candle_open creates two July 10 rows, double-counting that day in volume totals and potentially changing rolling indicators.
假设某 BTC/USD 日线接口以每天 UTC 00:00 的开盘时刻作为 K线时间戳。第一页以 7 月 10 日结束，第二页又从 7 月 10 日开始，因为请求的起止边界都包含端点。如果拼接后没有按 市场 + 周期 + K线开始时间 去重，就会出现两条 7 月 10 日记录，导致日成交量被重复计入，并可能改变滚动指标。
Now suppose the July 11 candle is requested at 12:00 UTC. It currently shows open 68,000, high 69,200, low 67,700, close 69,000, but it is only half complete. A later selloff could move the final close to 67,900. Store an is_final flag or infer finality from the documented interval boundary, exclude unfinished candles from historical backtests, and keep the retrieval time so a changing current candle is not mistaken for a historical revision.
再假设系统在 7 月 11 日 UTC 12:00 请求当天日线，此时返回开盘 68,000、最高 69,200、最低 67,700、最新价 69,000，但这根 K线只完成了一半。随后出现抛售，最终收盘价可能变为 67,900。应保存 is_final 标记，或根据文档中的周期边界判断是否收盘；历史回测应排除未完成 K线，同时保存抓取时间，避免把不断变化的当前 K线误判成历史数据修订。
How to compare free Bitcoin historical data APIs如何比较免费比特币历史行情 API
| Decision判断项 | Check检查内容 | Why it matters为何重要 |
|---|---|---|
| Market coverage市场覆盖 | Exchange pair, aggregate, or DEX pool交易所交易对、聚合价格或 DEX 池 | The same symbol can represent different markets.相同符号可能代表不同市场。 |
| GranularityK线粒度 | 1m, 5m, 1h, 1d and custom intervals1分钟、5分钟、1小时、日线与自定义周期 | Free plans may restrict intraday candles.免费层常限制分钟级数据。 |
| Historical depth历史深度 | Earliest candle, per-request window, pagination最早K线、单次窗口与分页方式 | A long backtest may need many calls or a paid tier.长周期回测可能需要多次调用或付费层。 |
| Limits and terms限制与条款 | Key, requests, attribution, caching, commercial use密钥、请求数、署名、缓存与商用 | “Free” does not always permit production use.“免费”不一定允许生产或商业使用。 |
| Freshness更新时效 | Current candle delay, cache duration, finalization time当前 K线延迟、缓存时长与最终确认时间 | A chart can tolerate more delay than an alerting system.行情图通常比预警系统更能容忍延迟。 |
| Data quality数据质量 | Gaps, duplicates, corrections, status page, provenance缺口、重复、修订、状态页与来源说明 | Backtests can silently change when data is repaired.数据修复可能让历史回测结果静默变化。 |
| Delivery交付方式 | REST, WebSocket, CSV, bulk downloadREST、WebSocket、CSV 与批量下载 | Historical loading and live updates need different paths.历史回填与实时更新通常需要不同通道。 |
Choose the source category before the provider先选择数据源类别，再选择供应商
Convenient for Bitcoin price history, market cap, and broad quote-currency support. Review auto-selected granularity, maximum free history, attribution, caching, and whether prices aggregate multiple venues.
适合获取比特币价格历史、市值及多种计价货币。应检查自动粒度、免费历史上限、署名、缓存条款，以及价格是否聚合多个交易场所。
Best for the exact BTC market traded on one venue. Verify symbol syntax, spot versus futures, earliest candle, maintenance gaps, pagination direction, and base or quote volume.
适合获取某个场所实际交易的 BTC 市场。应确认符号规则、现货或期货、最早 K线、维护缺口、分页方向，以及基础币或计价币成交量。
Useful for long research windows when an API would require thousands of calls. Check update cadence, corrections, schema versions, file completeness, licensing, and whether discontinued markets remain available.
适合需要长时间范围、通过 API 会产生数千次请求的研究。应检查更新频率、修订方式、字段版本、文件完整性、许可，以及停止交易的市场是否仍保留。
Choose this for blocks, transactions, fees, hashrate, difficulty, or UTXO-derived metrics—not as a substitute for BTC/USD candles.
当任务需要区块、交易、手续费、算力、难度或 UTXO 衍生指标时选择这类来源，不要把它当成 BTC/USD K线的替代品。
A practical free-tier selection checklist免费层选型检查清单
Record asset, quote currency, venue, spot or derivative, interval, earliest date, acceptable delay, and expected daily request count.
写清币种、计价币、交易场所、现货或衍生品、K线周期、最早日期、可接受延迟和预计日请求量。
Request a liquid pair and a thinly traded pair. Test maximum rows, pagination boundaries, missing periods, response headers, and rate-limit behavior.
分别请求高流动性和低流动性交易对，测试最大返回条数、分页边界、缺失周期、响应头和触发限频后的行为。
Check commercial use, attribution, retention, redistribution, derived-data, and display requirements instead of assuming public access means unrestricted use.
检查商用、署名、保存期限、再分发、衍生数据和展示要求，不要把“公开可访问”等同于“可无限制使用”。
Store provider, endpoint, market, request time, interval, timezone, schema version, and ingestion status with each dataset.
随数据保存供应商、端点、市场、请求时间、周期、时区、字段版本和摄取状态，便于切换与追溯。
How to get Bitcoin historical data with an API in Python如何用 Python API 获取比特币历史数据
A provider-neutral request and validation workflow与供应商无关的请求与校验流程
Before writing client code, record a small data contract: Bitcoin identifier, quote currency, venue if applicable, price or OHLCV output, interval, inclusive start and exclusive end, timezone, maximum acceptable staleness, and required provenance fields. This makes it possible to compare providers against the same requirement.
编写客户端代码前，先记录一个小型数据契约：比特币标识、计价货币、交易场所（如适用）、价格或 OHLCV 输出、周期、包含的开始时间与不包含的结束时间、时区、最大可接受延迟，以及必须保存的来源字段。这样才能在同一需求下比较不同供应商。
import requests
import pandas as pd
params = {"symbol": "BTC-USD", "interval": "1h",
"start": "2026-07-01", "end": "2026-07-07"}
rows = requests.get(API_URL, params=params, timeout=20).json()
df = pd.DataFrame(rows)
df["timestamp"] = pd.to_datetime(df["timestamp"], utc=True)
df = df.sort_values("timestamp").drop_duplicates("timestamp")
assert {"open", "high", "low", "close", "volume"} <= set(df.columns)Confirm whether it expects a coin ID, exchange symbol, base/quote pair, contract address, or pool address.
Use explicit UTC boundaries and a supported interval; paginate without overlapping or skipping candles.
Rename fields, parse timestamps, sort, deduplicate, inspect gaps, and record the provider and market provenance.
确认接口使用币种 ID、交易所符号、基础币/计价币、合约地址还是流动性池地址。
使用 UTC 边界和受支持的周期，分页时避免 K线重复或跳过。
统一字段、解析时间戳、排序、去重、检查缺口，并记录供应商与市场来源。
Pagination, rate limits, and retry safety分页、限频与安全重试
Historical endpoints often cap the number of candles returned per call. Advance the next request from the last confirmed timestamp, use the provider’s documented inclusive or exclusive boundary, and deduplicate after concatenation. For 429 and temporary 5xx responses, respect Retry-After, apply bounded exponential backoff, and never retry invalid parameters indefinitely.
历史接口通常限制单次返回的 K线数量。下一页应从最后一个已确认时间戳继续，并按文档区分包含或不包含边界；拼接后再次按时间戳去重。遇到 429 或临时 5xx 时，应遵循 Retry-After、使用有上限的指数退避，且不要无限重试错误参数。
Store the raw response before transforming it. Keep request parameters, retrieval time, final URL or endpoint version, response headers relevant to limits, and a checksum or immutable raw file. When a provider revises historical candles, this record lets you reproduce why a chart or backtest changed.
转换前先保存原始响应。同时保存请求参数、获取时间、最终 URL 或端点版本、与限频相关的响应头，以及校验和或不可变原始文件。当供应商修订历史 K线时，这些记录可以解释行情图或回测结果为什么发生变化。
Quality checks before charting or backtesting制图或回测前的数据质量检查
| Check检查项 | Expected rule预期规则 | Typical failure常见问题 |
|---|---|---|
| Price bounds价格边界 | low ≤ open/close ≤ high | Malformed fields or inconsistent adjustment字段错位或调整口径不一致 |
| Interval continuity周期连续性 | Timestamp difference equals the requested interval相邻时间戳差值等于请求周期 | Maintenance, illiquidity, or pagination gaps维护、低流动性或分页缺口 |
| Uniqueness唯一性 | One row per market and candle-open time每个市场与 K线开始时间仅一行 | Inclusive pagination duplicates包含边界的分页产生重复 |
| Completeness完整性 | No null OHLC; volume rule documentedOHLC 无空值；成交量规则有记录 | Empty candles encoded as zero or null空 K线被编码为零或空值 |
| Final candle最后一根 K线 | Closed before indicator or backtest use进入指标或回测前已经收盘 | Look-ahead or changing values未来函数或数值持续变化 |
Backtest warning: OHLCV bars do not contain tick order inside the candle. If both a stop and target fall within the same bar, bar data alone cannot prove which executed first. Use conservative execution rules or finer-grained data.
回测提醒：OHLCV K线不包含周期内逐笔成交的先后顺序。如果止损价与止盈价同时落在一根 K线范围内，仅靠该 K线无法判断哪个先成交，应使用保守成交规则或更细粒度数据。
How QVeris helps find a free Bitcoin historical data APIQVeris 如何帮助查找免费比特币历史数据 API
QVeris helps agents and developers discover and inspect callable capabilities. Open the QVeris provider details to review its available tools, inputs, and outputs, and connect the selected capability through the documented QVeris workflow.
QVeris 帮助 Agent 与开发者发现并检查可调用能力。可先使用 QVeris provider details 查找行情数据工具，核对输入输出，再按 QVeris 文档接入选定能力。
QVeris does not make a provider’s free tier unlimited or guarantee data quality. Verify the underlying source, limits, licensing, and candle semantics before production use.
QVeris 不会把供应商免费层变成无限调用，也不保证底层数据质量。生产使用前仍需核实来源、限制、许可与 K线定义。
Free Bitcoin historical data API FAQ免费比特币历史数据 API 常见问题
It summarizes a Bitcoin market’s open, high, low, close, and traded volume for each candle interval.
Yes. Some public endpoints and free tiers return BTC prices or candles, but history, rate limits, stability, attribution, and usage terms vary.
Call a historical endpoint with a Bitcoin coin ID or BTC pair, quote currency, date range, and interval, then validate the returned timestamps and price basis.
Yes, when the history, granularity, license, and quality fit your test. Inspect gaps, survivorship, market changes, and look-ahead bias.
Call a supported price or candle endpoint with the BTC identifier, interval, and time range; parse JSON into a dataframe and validate timestamps and fields.
No. Exchange candles represent trades on one venue, while aggregated candles combine or derive prices under a provider-specific methodology.
Usually no. Preserve the gap first. If your model requires a regular index, document any forward-fill or zero-volume synthetic candle explicitly.
REST is convenient for history and recovery; WebSocket is useful for live updates. Production systems commonly use both.
It depends on the source, interval, and plan. Check the earliest timestamp, maximum window per call, pagination, and whether older or intraday data requires an upgraded tier.
No. APIs may use different exchanges, aggregates, candle boundaries, quote currencies, outlier rules, and revision policies, so matching timestamps can still have different values.
它按每个 K线周期汇总比特币市场的开盘价、最高价、最低价、收盘价与成交量。
有。部分公共端点和免费层可返回 BTC 历史价格或 K线，但历史范围、限频、稳定性、署名与使用条款不同。
向历史数据端点传入比特币币种 ID 或 BTC 交易对、计价货币、日期范围与周期，然后校验返回的时间戳和价格口径。
可以，但历史范围、粒度、许可与质量必须符合测试要求，同时还要检查数据缺口、幸存者偏差、市场变化和未来函数。
向支持的价格或 K线端点传入 BTC 标识、周期与时间范围，把 JSON 转为数据表后校验时间戳与字段。
不同。交易所 K线代表单一场所成交，聚合 K线则按供应商自己的方法组合或计算多个市场价格。
通常不应该。应先保留缺口；如果模型要求规则时间索引，需要明确记录前向填充或零成交量合成 K线。
REST 适合历史回填与故障恢复，WebSocket 适合实时更新，生产系统通常会同时使用两者。
取决于数据源、时间粒度与套餐。需要检查最早时间戳、单次请求窗口、分页方式，以及更早或分钟级数据是否要求升级。
不一定。交易所覆盖、聚合方法、K线边界、计价货币、异常值规则和历史修订策略不同，即使时间戳相同也可能返回不同数值。