跳转到内容

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:面向开发者、产品团队和 ASO 专家,用于自动化自己的工作流程。
  • 合作伙伴 API:面向合作伙伴、代理商、服务商和平台,用于在 ASO.dev 之上构建集成。

开放会随着产品准备情况逐步推进:先开放单个 API 方法,再扩展更多能力。

开发者 API 面向已经使用 ASO.dev、并希望自动化重复工作的团队。它将作为 ASO.dev 订阅的补充能力开放,从 Pro 套餐开始提供

例如:

  • 获取应用数据
  • 获取报告结果
  • 将 ASO.dev 接入内部 BI 系统
  • 从自己的工具中启动后台任务
  • 将 ASO.dev 连接到 MCP 客户端和 AI 代理
  • 把数据传入自己的工作流程

MCP 是一个单独的场景。用户已经希望把 ASO.dev 接入 AI 工具,让代理可以获取数据、准备报告、检查应用,并帮助处理重复的 ASO 工作。API 会成为这类集成的基础。

开发者 API 与 MCP

如果你希望在 AI 客户端、MCP 服务器、内部代理、BI 或自动报告中使用 ASO.dev,请告诉我们代理需要获取哪些数据、需要执行哪些动作,以及请求大概会以什么频率运行。

发送 API / MCP 场景

我们希望开发者 API 解决真实任务,而不只是形式上复刻产品界面。因此,现在你的场景很重要:需要哪些数据、什么格式、请求频率,以及它出现在工作流程的哪个环节。

合作伙伴 API 面向外部集成和合作场景。

它可能适合以下情况:

  • 你在运营代理或咨询服务
  • 你在为客户构建内部平台
  • 你希望把 ASO.dev 数据加入自己的产品
  • 你计划将 ASO.dev 接入工作流程、分析、CRM 或报告系统

合作伙伴 API 的要求通常不同:访问权限、稳定合约、清晰限制和集成支持会更重要。我们会把它和开发者 API 分开处理。

合作伙伴 API 不是批量数据入口,而是服务之间的合作模式:需要明确的使用场景、清晰的用户价值,并尊重数据来源。

合作伙伴 API

如果你想讨论合作伙伴集成,请简要说明你的服务、使用场景、预计负载,以及用户会在哪里看到 ASO.dev 作为数据来源。

发送合作伙伴 API 申请

API 访问会使用用户 API token。每个用户都会有自己的 token 用于授权请求,请求会消耗团队的 credits

Credits 可以按包购买:包越大,单个 credit 的价格越低。

套餐会提供:

  • 月度
  • 年度

年度包的重点不是降低单个 credit 的价格,而是延长有效期。它更适合 API 请求量较小、但希望购买的 credits 不要一个月后就过期的团队。

套餐到期后,未使用的 credits 将失效。未使用 credits 不支持退款。

具体价格、限制和使用条款会在之后公布。

我们不想在了解真实负载和主要使用场景之前随便公布数字。

我们不打算一次性发布一个庞大的 API 列表。

最常被请求的方法会先进入 beta。之后,我们会根据准备情况和用户的真实需求继续扩展 API。这样对所有人都更好:

  • 不稳定的方法更少
  • 更容易保证数据质量
  • 能更快收集反馈
  • 更清楚哪些场景真正重要
  • API 变化时,更不容易破坏集成

如果你需要某个具体 API 方法,请发邮件告诉我们。场景描述越清楚,我们就越容易判断优先级、限制模型和响应格式。

建议说明:

  • 你需要哪些数据或动作
  • 想用 API 自动化哪个流程
  • 预计请求频率
  • 希望使用什么响应格式
  • 只需要访问自己的应用,还是也需要访问多个客户账号