ASO.dev API:开发者 API 与合作伙伴 API
开发中 即将上线
仅限专业版和市场营销会员专享功能。
我们正在准备 ASO.dev API。这是很多团队一直在问我们的新功能。
API 并不是给所有 ASO.dev 用户准备的。它更适合已经把 ASO 作为固定流程来做的团队:数据不仅要在产品界面里查看,还要进入报表、内部系统、客户流程、BI、MCP 和 AI 场景。
过去我们一直比较谨慎,不急着通过 API 出售数据。
不是因为 API 不重要。它很重要。很多团队已经不再满足于手动导出、表格和一次性报告。我们真正不想做的是把 ASO.dev 变成一个没有上下文、没有质量控制、没有使用责任、也没有清晰访问规则的原始数据出口。
还有一个产品层面的原因。ASO.dev 采用按用户席位计费的模式:产品价值不只是数据量,还包括团队如何在 ASO.dev 中分析应用、跟踪排名、准备报告、管理流程并做决策。
现在我们准备把 API 做得更稳:不是“把所有数据都倒出去”,而是在 ASO.dev 之上提供一个谨慎可控的产品层,有清晰的方法、受控访问、按请求消耗的 credits,并逐步扩展能力。
API 会作为 ASO.dev 的补充能力,而不是订阅的替代品:
- 仍然需要有效的 ASO.dev 订阅
- 用户席位仍然用于团队访问 ASO.dev 界面、项目、报告和设置
- credits 用于机器调用:请求、集成和自动化
- 每个用户都会有自己的 API token 用于请求授权
- 开发者 API 用于团队内部流程
- 合作伙伴 API 只会通过单独协议开放
- 不允许转售数据或构建竞争服务
- beta 期间,条款、价格、限制和方法都可能调整
我们目前在设计两条 API 路线:
开放会随着产品准备情况逐步推进:先开放单个 API 方法,再扩展更多能力。
开发者 API
Section titled “开发者 API”开发者 API 面向已经使用 ASO.dev、并希望自动化重复工作的团队。它将作为 ASO.dev 订阅的补充能力开放,从 Pro 套餐开始提供。
例如:
- 获取应用数据
- 获取报告结果
- 将 ASO.dev 接入内部 BI 系统
- 从自己的工具中启动后台任务
- 将 ASO.dev 连接到 MCP 客户端和 AI 代理
- 把数据传入自己的工作流程
MCP 是一个单独的场景。用户已经希望把 ASO.dev 接入 AI 工具,让代理可以获取数据、准备报告、检查应用,并帮助处理重复的 ASO 工作。API 会成为这类集成的基础。
如果你希望在 AI 客户端、MCP 服务器、内部代理、BI 或自动报告中使用 ASO.dev,请告诉我们代理需要获取哪些数据、需要执行哪些动作,以及请求大概会以什么频率运行。
发送 API / MCP 场景我们希望开发者 API 解决真实任务,而不只是形式上复刻产品界面。因此,现在你的场景很重要:需要哪些数据、什么格式、请求频率,以及它出现在工作流程的哪个环节。
合作伙伴 API
Section titled “合作伙伴 API”合作伙伴 API 面向外部集成和合作场景。
它可能适合以下情况:
- 你在运营代理或咨询服务
- 你在为客户构建内部平台
- 你希望把 ASO.dev 数据加入自己的产品
- 你计划将 ASO.dev 接入工作流程、分析、CRM 或报告系统
合作伙伴 API 的要求通常不同:访问权限、稳定合约、清晰限制和集成支持会更重要。我们会把它和开发者 API 分开处理。
合作伙伴 API 不是批量数据入口,而是服务之间的合作模式:需要明确的使用场景、清晰的用户价值,并尊重数据来源。
API Token、Credits 和限制
Section titled “API Token、Credits 和限制”API 访问会使用用户 API token。每个用户都会有自己的 token 用于授权请求,请求会消耗团队的 credits。
Credits 可以按包购买:包越大,单个 credit 的价格越低。
套餐会提供:
- 月度
- 年度
年度包的重点不是降低单个 credit 的价格,而是延长有效期。它更适合 API 请求量较小、但希望购买的 credits 不要一个月后就过期的团队。
套餐到期后,未使用的 credits 将失效。未使用 credits 不支持退款。
具体价格、限制和使用条款会在之后公布。
我们不想在了解真实负载和主要使用场景之前随便公布数字。
API 方法与需求
Section titled “API 方法与需求”我们不打算一次性发布一个庞大的 API 列表。
最常被请求的方法会先进入 beta。之后,我们会根据准备情况和用户的真实需求继续扩展 API。这样对所有人都更好:
- 不稳定的方法更少
- 更容易保证数据质量
- 能更快收集反馈
- 更清楚哪些场景真正重要
- API 变化时,更不容易破坏集成
如果你需要某个具体 API 方法,请发邮件告诉我们。场景描述越清楚,我们就越容易判断优先级、限制模型和响应格式。
建议说明:
- 你需要哪些数据或动作
- 想用 API 自动化哪个流程
- 预计请求频率
- 希望使用什么响应格式
- 只需要访问自己的应用,还是也需要访问多个客户账号