选择合适的免费金融 API
数据、来源与示例

快速摘要

按使用场景选择免费金融 API

最合适的 API，应当让数据契约与产品要完成的决策相匹配。看板、估值 Notebook、回测系统和 AI 研究 Agent 都会请求“金融数据”，但它们需要的时间戳、标识符、更新频率和使用权并不相同。应先定义输出，再反推所需数据源。

第一轮测试最好只保留两到三个候选供应商。日频公司研究应优先检查申报文件、基本面、公司行动和批量接口；日内提醒则应优先检查行情源覆盖、延迟、连接行为以及展示结果所需的许可证。同一供应商可能非常适合一种流程，却完全不适合另一种流程。

你需要哪些金融 API 接口？

先明确你的决策或产品目标。投资组合应用需要当前价格，估值模型需要基本面，宏观研究需要利率、通胀、就业与 GDP，Agent 工作流则需要稳定字段与来源元数据。

免费的金融 API 通常不止一个接口。市场接口返回行情或周期数据，公司接口跟随财报周期更新，经济指标则依据官方发布日历更新。比较供应商之前，应先明确资产类别、地区、频率、历史深度、可接受延迟和响应格式。

对于研究任务，只有价格字段通常不够。你还可能需要交易日历、代码变更、退市记录、币种、交易所标识和公司行动。这些参考字段能减少幸存者偏差，也能让价格与基本面正确关联。来源清楚、标识一致的小型数据集，往往比来源不明、复权规则模糊的大型数据源更有价值。

如何比较免费的金融 API

没有一种来源适合所有工作流。交易所和监管机构最接近一手记录，但文件往往需要更多清洗；市场数据 API 查询方便，不过免费套餐通常以较低调用限额、延迟行情、较短历史或较窄市场覆盖来换取便利。券商数据适合个人交易流程，而可下载文件更适合可重复的研究分析。

不要只看功能清单，最好用同一组小样本横向测试：选择一只高流动性股票、一只成交稀疏的证券、一个曾更换代码的标的，以及包含拆股或分红的日期。对比时间戳、缺失记录、数值精度、复权方式和错误信息。即使字段名称相同，这种测试也能快速发现不同供应商对交易时段和指标定义的差异。

接入前如何评估免费金融 API

功能清单容易复制，却很难直接比较。更可靠的评估方法，是对每个候选 API 使用相同的代表性请求、预期输出和失败测试，并把结果记录在评分表中。这样，“免费”“实时”和“全球覆盖”就会变成可验证的定义，而不是营销标签。

1. 覆盖范围与标识符

列出真正需要的交易所、国家、资产类别、证券类型和代码状态。测试正常上市与退市标的、主次上市、ETF、优先股以及曾经变更代码的证券。连接数据时，应优先使用永久标识符或明确的映射表，而不是只靠股票代码，因为代码可能被重复使用，也可能因交易场所不同而变化。

2. 时效、时间戳与交易时段

要明确每个时间戳表示事件发生时间、交易所时间、K 线结束时间、供应商入库时间，还是发送时间。盘前、正常交易和盘后时段应分别验证。“实时”描述的是延迟，并不必然代表完整市场覆盖；实时单一场所行情与综合行情可能返回不同的价格和成交量。

3. 时点数据质量与修订

对于基本面和宏观数据，要判断 API 是否保留历史某一时点已知的数值，还是只提供最新修订值。需要记录申报日期、接收时间、财务期间、单位以及修订或重述状态。只要模型声称能够重现历史决策，时点数据就是必要条件。

4. 可靠性与失败行为

应测试无效代码、缺失日期、额度耗尽、超时和部分返回。客户端必须区分“确实没有观测值”和“供应商请求失败”。记录 HTTP 状态、重试响应头、供应商错误信息和缓存数据的新旧程度。在没有提示的情况下改用过期数据或零值，往往比明确报错更危险。

5. 许可与输出权限

个人分析、企业内部使用、公开展示、非展示用途、衍生数据、模型训练和再分发应分别核对。API Key 能正常调用，只能证明技术访问成功，并不能证明可以发布或转售结果。应把适用套餐和许可链接与接入决策一起保存，并在产品或用户群发生变化时重新检查。

实用的金融 API 接入流程

可靠的工作流会把“发现数据源”和“正式使用”分开。先查看供应商文档与示例响应，再发起小规模请求，保存原始返回，并转换为自己的稳定字段结构。数据进入图表、模型、表格或 Agent 之前应先经过验证。这样未来更换数据源时，无需重写整个产品。

使用 API 时，应缓存不要求秒级更新的结果，对临时失败采用指数退避，并记录请求时间、参数、状态码和供应商时间戳。使用 CSV 时，应把原始文件与清洗后的表格分开保存，同时记录下载日期、分隔符、编码和时区。两种方式都需要可重复的更新策略，避免新旧数据在无提示的情况下混合。

带验证步骤的免费金融 API Python 示例

有用的第一段脚本不应只打印一个数值。下面的示例从 SEC EDGAR API 请求公司事实数据，保留来源和获取时间，检查返回类型，并展示帮助分析师解释数值的申报元数据。SEC 文档说明，data.sec.gov 提供无需 API Key 的 JSON API；自动访问仍须遵守 SEC 访问政策，并正确标识请求者。

import os
from datetime import datetime, timezone

import requests

cik = "0000320193"  # Apple Inc.; CIK must contain 10 digits
url = f"https://data.sec.gov/api/xbrl/companyfacts/CIK{cik}.json"
headers = {
    "User-Agent": os.environ["SEC_USER_AGENT"],
    "Accept-Encoding": "gzip, deflate",
}

response = requests.get(url, headers=headers, timeout=20)
response.raise_for_status()
payload = response.json()

if "facts" not in payload or "entityName" not in payload:
    raise ValueError("Unexpected SEC response schema")

revenue = payload["facts"]["us-gaap"]["RevenueFromContractWithCustomerExcludingAssessedTax"]
recent_usd_facts = revenue["units"]["USD"][-5:]

result = {
    "source": "SEC EDGAR Company Facts",
    "retrieved_at": datetime.now(timezone.utc).isoformat(),
    "entity": payload["entityName"],
    "taxonomy_label": revenue["label"],
    "recent_facts": recent_usd_facts,
}

print(result)

运行前，将 SEC_USER_AGENT 设置为应用名称和可联系的邮箱。生产环境中不能直接假设数组最后一项就是“正确值”，而应按表单、财务期间、申报日期、单位、frame 和接收时间过滤，并明确如何处理修订文件和重复事实。大规模提取时，应使用 SEC 批量归档，而不是持续重复调用单家公司接口。

计算真实请求预算与隐藏成本

仅看每分钟或每天请求次数，无法判断免费套餐是否够用。应计算生成一次完整答案所需的全部调用路径：

假设观察列表有 25 家公司，每次刷新需要行情、公司资料、利润表、财务比率和近期新闻五个接口，每天刷新四次，在重试前就需要 500 次调用。预留 10% 重试空间后变成 550 次，交易日历、汇率换算和代码映射还会增加公共调用。批量接口、缓存，以及把低频变化的基本面与高频变化的价格分开更新，都能显著降低请求量。

API 标价之外的成本

• 标准化：把供应商特有字段、标识符、币种、时区和空值规则映射为稳定的内部结构。
• 质量控制：发现缺口、重复、修订、过期观测、错误复权和异常值。
• 运行维护：缓存、重试队列、监控、供应商状态检查、密钥轮换和故障调查。
• 许可：取得公开展示、专业用户、衍生输出或再分发所需的权利。

上线前应提前定义升级触发条件，例如正常使用量持续接近安全额度上限、需要更低延迟或综合行情、历史深度不足、缺少公司行动，或需要面向客户的许可。升级决策应由产品行为和风险触发，而不是设定一个随意日期。

用 15 分钟判断免费套餐是否真的适合

与其继续浏览功能清单，不如做一次可重复的小型冒烟测试。15 分钟当然不能证明接口已经达到生产可靠性，但足以暴露最常见的问题：覆盖不完整、时间戳含义不清、证券标识不稳定、空值没有说明、额度无法支撑实际负载，或使用许可与产品场景不匹配。

免费金融 API 检查清单

数据质量不只是判断一个数字“看起来是否合理”。每条记录都应对应正确的交易场所、交易时段、币种和时区，还要确认时间戳表示成交时间、K 线结束时间，还是供应商发送时间。构建指标或回测时，应记录如何处理缺失交易日、零成交量、重复行、异常值、拆股、分红以及重述后的财务数据。

• 确认市场、交易所、资产类别、周期和历史深度。
• 记录价格是否复权，以及拆股和分红等公司行动的处理方式。
• 为每条结果保留来源、时间戳、币种、时区和请求参数。

最后，许可证应当和字段说明一样认真阅读。免费访问可能允许个人分析，却限制公开展示、再分发、自动抓取、模型训练或商业产品。建议在项目中保存适用条款的链接或副本，并在供应商调整套餐时重新检查。如果数据用于交易、合规或面向客户的决策，关键数值还应与权威来源交叉核验。

常见问题

外部参考链接