免费 ETF 数据 API
数据源、额度与 Python
寻找可提供 ETF 行情、历史数据、持仓和基金资料的免费接口，
并在开发前核对额度、许可与实际请求结果。
摘要
明确需要实时行情、历史 OHLCV、复权价格、持仓、净值、资产规模、费率还是分红数据。
核对每日调用量、瞬时频率、数据延迟、历史深度、署名要求、再分发与商用许可。
选择流动性较高的代码，检查时间戳和空值，再接近公开频率上限重复调用。
QVeris 可帮助 Agent 发现并调用可用的金融数据能力，避免把每个供应商写死在工作流中。
免费 ETF 数据 API 应提供哪些数据
实用的 ETF 数据接口不只是一个报价端点。应按应用真正使用的数据集选择数据源，并为每次响应保留观测时间。
ETF 数据应被建模为一组更新时间不同的关联数据集。行情可以盘中更新，官方净值通常对应特定估值时点，持仓可能滞后数日甚至更久，资产规模和份额会随申购赎回变化，分派还包含宣布日、除权日、登记日和支付日。一个笼统的 timestamp 无法描述全部口径。
行情与 ETF 历史数据
用于图表和回测时，应核对日线或分钟 OHLCV、复权方法、拆分与分红处理、交易所时区以及历史深度。免费方案中的“历史数据”可能只包含近期窗口。
ETF 基金资料、净值、费率与标识符
基金研究通常需要代码、名称、交易所、币种、发行人、成立日期、净值、资产规模、费率、跟踪指数、类别，以及 ISIN 或 FIGI 等稳定标识。
ETF 持仓与资产配置数据
ETF 持仓接口应提供成分标识、名称、权重和数据日期，最好还包含行业或资产类别配置。前十大持仓并不等于完整持仓。
分派、公司行动与总回报
应保存分派类型、金额、币种、宣布日、除权日、登记日和支付日，以及拆分或份额类别事件。复权价格与总回报序列还必须说明再投资和税务假设。
基金、份额类别与上市标识
应分别保存法律基金、份额类别、交易所上市、代码、交易币种、注册地和稳定标识。同一策略可能有多地上市或汇率对冲份额，而重复使用的代码在不同时期也可能代表不同工具。
Alpha Vantage 官方文档列出了 ETF Profile & Holdings 接口，包含资产规模、费率、换手率、持仓及资产与行业配置。当前权限和限额应以官方文档为准。
如何比较免费 ETF 数据接口
不要只依据营销页面给数据源排名。应在实时文档中核对每项要求，并调用计划使用的具体端点验证响应。
| 检查项 | 需要核对 | 影响 |
|---|---|---|
| 覆盖范围 | 国家、交易所、在市与退市 ETF、代码映射。 | 避免静默缺失与生存者偏差。 |
| 字段 | 行情、历史、持仓、净值、规模、费率、分红。 | 报价接口未必能支持基金研究。 |
| 时效 | 实时、延迟、日终，以及持仓数据日期。 | 不同任务能容忍的延迟不同。 |
| 免费额度 | 每分钟/每日请求数、历史窗口、端点权限。 | 免费 Key 可能只适合原型验证。 |
| 许可 | 个人或商用、展示、缓存、署名、再分发。 | 获得 API 权限不代表可以再分发数据。 |
| 标识体系 | 基金、份额类别、上市、代码历史与 ISIN 或 FIGI 映射。 | 避免重复基金与错误关联。 |
| 日期口径 | 报价时间、净值日、持仓日、规模日与分派日期。 | 避免把不同步的数据误当作同一时点。 |
| 完整性 | 完整或前十大持仓、现金、衍生品与权重合计。 | 决定能否计算敞口与重合度。 |
用 Python 测试 ETF API 免费额度
1. 请求文档中的 ETF 端点
使用数据源当前文档中的端点和自己的 API Key。下例沿用 Alpha Vantage 文档中的 ETF profile 形式；运行前请替换 Key 和代码。
import os
import requests
params = {
"function": "ETF_PROFILE",
"symbol": "QQQ",
"apikey": os.environ["ETF_API_KEY"],
}
response = requests.get(
"https://www.alphavantage.co/query",
params=params,
timeout=20,
)
response.raise_for_status()
data = response.json()
print(data)2. 不要只验证 HTTP 200
确认响应中的代码、字段名、数据日期、数字类型、币种、缺失值，以及 JSON 内可能出现的限流或权限信息。
3. 记录免费额度边界
记录文档日期、端点、实际延迟、允许调用量和许可链接。免费方案与权限可能变化，上线前应再次核对。
4. 核对相互关联的 ETF 数据集
用稳定标识关联基金资料、行情、净值、持仓、规模和分派响应，不要只依赖代码。应拒绝不可能的日期顺序，标记陈旧组合数据，并解释权重合计为何偏离文档所述覆盖范围。
5. 测试事件日与代码历史
选取分派、拆分、代码变更、新基金成立、清盘和市场休市附近样本，核对复权价格、回报计算、状态字段，以及旧上市记录到当前标识的映射。
6. 同时保存原始证据与规范化输出
保存原始响应、供应商、端点、抓取时间、有效日期、结构版本和规范化代码。持仓或历史序列之后发生修订时，才能追溯差异来源。
使用 QVeris 连接 ETF 数据能力
QVeris 不是底层 ETF 交易所数据源，也不会把付费数据变成免费数据。它帮助 Agent 以一致流程发现、检查并调用可用能力。接入前可查看匹配的 ETF 数据能力、在 在线体验中测试候选能力，并阅读 QVeris 文档。
- 选择能力前先明确 ETF 字段、市场范围与时效要求。
- 首次生产调用前检查供应商元数据、标识体系、日期口径、参数、权限信息和输出结构。
- 把行情、净值、持仓、分派和基础资料拆成独立要求，并分别设置时效容忍度。
- 在应用设计中保留许可、署名、缓存、原始证据与下游展示规则。
FAQ
部分市场数据服务商提供免费 Key 或有限免费额度，但端点、历史深度、时效和请求量通常有限，应以当前官方文档为准。
申请 API Key，按官方文档请求 ETF 代码对应的时间序列端点，再验证时区、复权方式、字段类型、缺失值和限流信息。
通常需要。Key 用于识别账户和执行额度限制，应保存在环境变量中，不要写入浏览器代码或公开仓库。
只有当前许可明确允许你的具体用途时才可以。展示、内部分析、缓存和再分发可能适用不同条款。
检查数据是否仅含前十大持仓，是否提供完整成分、权重、稳定标识符、数据日期与更新频率。
核对分钟与每日调用量、端点权限、历史窗口、数据延迟、缓存、署名、再分发和商用权利。
行情在交易时段持续变化，持仓则可能按日、定期或供应商节奏发布。应分别保存有效时间，不能把旧组合快照描述成盘中数据。
应区分法律基金、份额类别和交易所上市，并保留交易币种、注册地、代码历史与稳定 ID，使行情准确关联到对应工具，又不会重复计算底层策略。
它需要历史证券池、已清盘基金、时点基金资料与持仓、公司行动、分派、明确复权规则和数据可用日期，而不只是今天的资料加过去价格。