股票API接口的费用、权限与接入限制
TickDB Research ·
股票API接口的费用、权限与接入限制
股票API接口怎么收费，付费后能用哪些数据，接入时又有哪些限制？**费用通常取决于数据类型、套餐和计费周期；权限需要逐项确认市场、接口及历史范围；接入限制则要分别检查调用频次、单次数据量和实时订阅额度。**拿到密钥或购买一个套餐，都不能直接推导出“所有股票数据随便用”。
先给出可落地的答案：Tushare 个人历史分钟数据公开价为 2,000元/年，属于独立权限；TickDB 官网基础版公开价为 99美元/月，列示 60次API调用/分钟、50个同时订阅、1个WebSocket连接。两者的数据范围与交付方式不同，不能只按价格高低选型。免费项目也要看边界：前者的低积分档开放有限数据，后者列示7天精选品种试用。下面按“费用—权限—容量”逐项拆开。价格与文档核对日期为2026年10月18日，下单前以最新页面和账户实际权益为准。
股票API接口多少钱？先看买到的具体数据
**先按同一种数据、同一种用途和同一个计费周期对价，才能判断成本。**日线、历史分钟和实时分钟并非同一项权益；积分门槛与独立付费权限也不能混用。
Tushare 官方权限页列出的部分个人档位如下：
| 项目 | 公开费用或门槛 | 选型时要确认的边界 |
|---|---|---|
| 120积分档 | 0元/年 | 不复权日线；50次/分钟、每天8,000次 |
| 2,000积分及以上档 | 200元/年起 | 按接口要求判断可用范围，不能视为全接口通行证 |
| 历史分钟数据 | 2,000元/年 | 独立权限，不能用普通积分档直接替代 |
| 实时分钟数据 | 1,000元/月 | 月费项目，不能误读为年费 |
同页对机构用户另有价格说明，列示为个人价格的10倍。采购时还应确认账号主体及具体适用项目；“机构价格”本身不等于获得对外转售数据的许可。
对于月度订阅服务，要把价格与容量放在一起看。例如前述基础版的60次/分钟与50个同时订阅，是两个不同维度的上限：一个约束请求频次，一个约束实时订阅数量，不能相互替代。官网展示的试用也有期限和品种范围，不能理解为全市场永久免费。
最终预算还要计入历史补数、重复请求和断线恢复带来的用量。只有把“数据类别、使用主体、使用范围、更新频率、计费周期”写在同一张需求单上，报价才有可比性。
来源：Tushare 官方《权限说明》及相关积分档位；订阅价格取自上述服务官网定价区，均于2026年10月18日核对。
有API Key就有权限吗？还需要确认数据范围和用途
**API Key首先用于身份验证；账户有效不代表所有市场、所有接口和所有历史区间都已开放。**即使某次请求成功，对外展示、再分发等用途仍需依据服务条款或合同另行确认。
实际接入可以分成三个层次：先看密钥和套餐是否有效，再测试目标市场、接口和日期范围，最后确认项目的数据使用范围。
以 TickDB 为例，官方APIKey管理接口可以查询套餐标识、状态、到期时间和剩余秒数。下面是文档中的最小请求，替换占位密钥后可在自己的环境执行：
curl -H "X-API-Key: YOUR_API_KEY" \
"https://api.tickdb.ai/v1/apikeys/subscriptions"
成功响应的业务状态码为0。重点检查plan、status、expires_at和remaining_seconds；其中active表示密钥有效，不代表该响应已经列明全部数据权限或授予对外使用权。本文仅核对文档，未使用付费账户执行该请求。
图1：接入核对示意。账户状态查询只是第一步；市场、接口、历史范围及实际用途仍需分别确认。非官方界面截图。
错误响应也能帮助区分问题：官方文档将请求频率超限、交易产品未开放、历史范围超限、接口无权访问以及频道无权订阅分别定义为不同业务错误。客户端应同时检查HTTP状态与业务码，而不是把所有失败都当成网络问题反复重试。
开源股票数据接口同样要分清许可边界。zhangxiangliang/stock-api仓库采用MIT许可，README说明其数据来自第三方，并列有使用限制和免责声明。代码许可解决的是项目代码的使用条件，不能替代上游数据的使用授权，也不能证明服务有商业级可用性承诺。
来源：官方《APIKey管理》《错误码说明》及 stock-api README，2026年10月18日核对。
接入限制怎么看？先把业务需求换算成调用量
**至少分别检查每分钟请求数、每日或滚动窗口额度、单次返回量，以及WebSocket连接数与订阅数。**它们限制的是不同资源，一项满足并不意味着整体可用。
假设要轮询500只股票，每5秒刷新一次，接口允许每次请求50只，每天运行240分钟：每轮需要10次请求，平均每分钟120次，每天28,800次。再预留20%的重试与恢复余量，预算为144次/分钟、34,560次/日。这里的运行时长和批量大小都是示例参数，不代表任一供应商对所有接口的承诺。
下面的代码只做离线预算，可按实际接口修改参数：
from math import ceil
symbols = 500
batch_size = 50 # 按目标接口实际支持值修改
refresh_seconds = 5
active_minutes = 240 # 本例假定运行时长
headroom = 0.20 # 预算余量，不是实测失败率
requests_per_round = ceil(symbols / batch_size)
average_rpm = requests_per_round * 60 / refresh_seconds
rounds_per_day = ceil(active_minutes * 60 / refresh_seconds)
daily_requests = requests_per_round * rounds_per_day
print("每轮请求数:", requests_per_round)
print("平均每分钟请求数:", average_rpm)
print("含余量每分钟预算:", ceil(average_rpm * (1 + headroom)))
print("基础每日请求数:", daily_requests)
print("含余量每日预算:", ceil(daily_requests * (1 + headroom)))
图2：假设轮询场景的请求预算，非接口实测。平均频次之外，还需检查突发限制、连接数和订阅数。
把这个需求代入 TickDB 基础版公开额度，基础轮询就已超过60次/分钟；若改用实时订阅，同时关注500只也超过50个同时订阅的额度。这里得到的是“当前方案超出该档容量”的判断，下一步应调整刷新策略、缩小关注范围或核对其他套餐，而不是仅因能成功请求一只股票就认定方案可上线。
批量大小也会改变结论：如果目标接口每次只能查1只，同样500只、5秒刷新就需要平均6,000次/分钟。即使平均量不超额，把一轮请求集中发出也可能触发短窗口限制；多个进程共用账号时，还需确认额度是否共享。
历史补数要另算。Tushare 的stk_mins文档列示单次最多8,000行、每分钟500次、滚动24小时累计30万次，且需独立权限。这里的8,000是返回行数，不是8,000只股票；补数计划还要按标的、日期和每条记录的粒度拆批。
遇到官方页面口径不同，也不要自行取较宽松的数值。例如Tushare日线接口页列示500次/分钟，而低积分档权限页列示50次/分钟。应记录差异，并用账户所属档位、实际接口及服务方确认结果确定有效额度。
来源：上述服务官网定价区、Tushare《股票历史分钟行情》《日线行情》及权限说明，2026年10月18日核对。
购买前，怎样验证这个股票数据接口适合项目？
**先用目标数据和真实部署环境做小规模验证，再决定套餐。**验证至少覆盖以下几项：
- 数据是否符合任务：选取实际要用的市场、标的、复权方式、粒度和历史日期，检查字段、时区、交易日及空值。
- 权限是否覆盖需求：测试目标接口与历史范围，并单独确认对外展示、共享或再分发等实际用途。
- 容量是否足够：将正常刷新、历史补数、重试和恢复分别预算，检查频次、返回量及实时订阅限制。
- 部署条件是否影响调用：在正式部署地区测试网络和搜索功能；stock-api README明确提示部分搜索功能存在境外IP限制，不能只依据本地调试结果判断。
如果项目只需要低频日线研究，可先核对免费档的覆盖与额度；如果需要历史分钟回测，应重点确认独立权限、历史范围和批量返回限制；如果需要多标的实时展示，就应把订阅数、连接数、恢复策略和展示用途一起列入验收。选择依据是项目需求与实际权益是否匹配，而不是“有免费接口”或“套餐标注实时”这一个条件。