API 变现这条路：把能力做成接口卖给开发者，先算清楚每一次调用的成本

假设你写了一段代码，传进去一个网址，就能返回这个网页的截图。你可以给它做一个网页界面，让普通用户自己上传网址、下载截图，这是 SaaS 的卖法；也可以只提供一个接口，让别的开发者在自己的程序里调用它，每调一次返回一张图，这就是 API 的卖法。

ScreenshotOne 就是按 API 这种方式卖的。它是一个专门做网页截图的 API，每月免费 100 张，付费套餐从 $17/月（2,000 张）起，超出套餐的部分再按张计费。用它的人大多是开发者，他们会把截图功能接进自己的产品里，用来做链接预览、网页存档这类功能。

**同一个能力，做成 SaaS 还是做成 API，后面的定价、成本和获客方式都不一样。**这篇文章主要讲 API 这条路：什么能力适合做成 API、怎么收费、怎么算成本，以及上线之后会遇到哪些问题。

API 和 SaaS 卖的是同一个能力，但客户不一样

SaaS：你来做界面，用户在你的界面里完成操作，他们直接用的是你的产品
API（Application Programming Interface，应用程序接口，可以理解为“给程序用的入口”）：你只提供接口，别的开发者把你的能力接进他们的产品，最终用户甚至不知道你的存在

API 方式会带来了两个好处。

第一，你的客户是开发者，他们很清楚自己实现同样的功能要花多少工程时间，只要你的价格比他们自己做便宜，他们就愿意付费。

第二，从注册、拿到 Key、调用到扣费，整个流程都可以是自动的，不需要像卖企业软件那样一单一单去谈。

但 API 也有一个 SaaS 没有的问题：**SaaS 多一个用户，成本几乎不变；API 每多一次调用，你就要多付一份服务器或第三方服务的钱。**所以做 API，定价之前一定要先把成本算清楚，文章后面会单独讲怎么算。

同一个能力，两种卖法：SaaS 与 API 的结构差异

什么样的能力适合做成 API

适合做成 API 的能力，通常有一个共同点：别的开发者需要在自己的程序里反复调用它。如果用户只是偶尔用一次，比如一年转换一次文件格式，做成网页工具会更适合；只有需要每天、每次请求都自动调用的能力，才值得做成 API。

常见的有以下几类：

数据类：你采集、整理了某一类别人很难拿到的数据，比如商品价格、行业数据、公开信息的汇总，或者你有一套处理流程，能输出别人没有的结果
AI 能力类：你训练了一个特定领域的模型，或者在通用大模型的基础上做了提示词、后处理和结果校验，让某个具体任务的效果比开发者自己直接调用大模型更好
工具函数类：图片处理（压缩、格式转换、OCR，也就是从图片里识别出文字）、网页截图、PDF 解析、地址校验等，这类功能单一，但几乎每个产品都可能用到
流程自动化类：把一个比较复杂的流程封装成一次调用，比如自动生成发票、翻译并发布内容

判断要不要做，可以问自己一个问题：**开发者自己实现这个能力的成本，是不是明显高于你的 API 价格？**这里的成本不只是写代码的时间，还包括后续的维护，比如截图服务要处理各种网页的兼容问题，数据类 API 要持续更新数据。对方自己做一遍要花几天、之后还要一直维护，而你的价格只要每月几十美元（一两百元人民币），这笔账对他来说就很容易算清楚。

四种常见的收费方式

按调用次数计费

用户调用一次，你扣一次钱，用多少付多少（Pay-as-you-go）。

代表案例：OpenAI API 按 Token 计费（Token 是大模型处理文本的计价单位，一段中文大致可以按字数来估算），Twilio 按短信条数计费。

优点：用户不用先付一笔订阅费，试用的门槛很低
缺点：你的收入会随着客户的用量波动，很难预测下个月能收多少

比较适合用量差异很大、新用户多的 API。

订阅制，每月包一定的调用额度

用户每月付固定的费用，换取一定的调用次数。大多数数据类 API（天气、汇率等）都是这么收费的。

优点：收入稳定，方便你规划成本
缺点：用量少的用户会觉得浪费，而少数用满额度的用户可能把你的利润吃掉，后面算成本时会具体讲

实际上，很多 API 用的是订阅加超额按量的混合方式。以 ScreenshotOne 为例：

套餐	月价	每月包含	超出后每张
免费	$0	100 张	无
Basic	$17	2,000 张	$0.009
Growth	$79	10,000 张	$0.006
Scale	$259	50,000 张	$0.004

从这张表可以看出两个设计：套餐越大，每张的单价越低，鼓励用户升级；用超了也不会直接停掉服务，而是按张继续计费。这样用户不用担心业务高峰时截图功能突然不能用了，你也不会因为有人超量调用而白白承担成本。

免费额度加付费

每月给一定的免费调用次数，超过之后按量计费或者升级套餐。这是现在最常见的方式，因为开发者在付费之前，几乎都要先跑通一次请求，确认效果。

但免费额度不能随便给。免费用户每一次调用产生的成本，都是由你来承担的，免费额度怎么定，后面会单独算一笔账。

在 API 市场上架出售

把 API 发布到第三方平台上，平台帮你带来用户、处理计费，代价是平台要抽成。市场既是一种收费方式，也是一个获客渠道，具体有哪些平台、现在的情况怎么样，放到后面的获客部分来讲。

四种收费模式

上线前先算清楚每一次调用的成本

这是做 API 最重要的一步，也是很多人会跳过的一步。

单次调用的成本怎么拆

一次调用的成本可以拆成四部分：

计算成本：跑一次你的代码，要占用多少 CPU 或 GPU 时间
第三方成本：如果你在背后调用了别人的服务（大模型、地图、短信、数据源），这部分会随着调用量同比例增长
流量和存储：带宽、结果缓存、日志等
分摊的固定成本：数据库、监控、域名、文档托管等每个月固定要付的钱，除以每月的总调用量

前两项决定了你的定价下限。后两项在调用量很小的时候，反而可能是主要的开销，因为固定成本还没有被足够多的调用分摊掉。

一次调用，钱花在哪

转售型 API 的毛利要留足

如果你的 API 本质上是包装了别人的能力，最典型的就是在大模型外面加一层，那你的成本会随着调用量同比例上涨，用户越多，成本也越高，规模变大并不会让单次成本变低。

这种情况下，定价要明显高于底层成本，而不是只加一点点。因为底层服务涨价、你的提示词变长、用户传进来的内容比预期大，任何一项都可能直接把利润吃掉。而且如果你和别人的区别只是“多调了一层”，别人也很容易做出一样的东西，价格很快就会被压下来。

反过来，如果你卖的是自己的算法、自己积累的数据，单次成本主要是算力，调用量越大，固定成本摊得越薄，这才是能长期做下去的结构。

套餐要按用满额度的用户来验算

订阅制最常见的亏损方式是这样的：你按“平均每个用户每月调用 2,000 次”的估计，定了一个 $29 包 10,000 次的套餐。但调用量的分布通常很不均匀，少数重度用户会贡献大部分的用量，他们会把 10,000 次全部用完。

举个例子（下面的成本是假设的数字，只用来说明怎么算）：如果你做了一个类似的截图 API，每张截图的成本是 $0.003，那么：

用户只用 2,000 次时，成本是 $6，你赚 $23
用户把 10,000 次全部用完时，成本是 $30，比 $29 的月费还高，这个用户每个月都在让你亏钱

动画：$29 的月费放在天平左边，每 1,000 次调用的成本落一块 $3 砝码到右边；用 2,000 次还赚 $23，用满 10,000 次右边压下去，亏 $1

所以验算套餐时要用满额用量：假设每个用户都把额度用光，你还能不能赚钱？如果不能，这个套餐就是在亏钱，只是暂时被那些没用满的用户补贴着。对比一下 ScreenshotOne 的 Growth 套餐，$79 包 10,000 张，平均每张 $0.0079，和超额单价一样，都给成本留出了比较大的空间。

别用平均数定价

免费额度要按最多会有多少免费用户来算

免费额度每个月的成本，可以这样估算：

单次成本 × 每人免费额度 × 免费用户数

前两个数是你能控制的，第三个数会随着曝光变多而越来越大。还是按上面假设的 $0.003 来算，每人每月免费 100 次，如果有 1,000 个免费用户都用满，你每个月就要承担 $300。

所以定免费额度时可以参考这几点：

免费额度的作用是让开发者跑通第一个请求，确认效果，而不是让他们长期免费使用
额度够测试、但不够放进正式环境使用，是比较合理的范围。ScreenshotOne 每月 100 张，就属于这一类
如果你的单次成本很高（比如在背后调用大模型），可以考虑“注册送一次性的总额度”，代替“每月免费 N 次”。每月免费是一笔长期持续的支出，一次性额度用完就结束了

先按量上线，再设计套餐

如果你对用量分布心里没底，可以先只开按量计费，先跑一两个月看看情况，等看清楚真实的用量分布之后，再设计套餐。

**先上套餐，相当于在没有数据的情况下盲猜一个价格。**猜低了之后想涨价，又很容易导致用户流失，因为换一个 API 对开发者来说并不难，后面讲黏性时会具体说。

搭建：一个端点、一套 Key 和一份文档

部署方式

如果你的能力是一段 Python 或 Node.js 代码，可以从下面几种方式里选：

Modal：适合 Python，尤其是需要 GPU 跑模型的场景。给函数加上装饰器就能部署成一个 API，按实际运行时间计费，没有调用时不会产生服务器空转的费用。

import modal
 
app = modal.App("my-api")
 
@app.function()
@modal.fastapi_endpoint()
def process(text: str) -> dict:
    result = your_algorithm(text)
    return {"result": result}

FastAPI + Railway / Fly.io：用 FastAPI 写接口，再部署到 Railway 或 Fly.io，成本低，控制也比较灵活。

Cloudflare Workers：代码运行在离用户最近的节点上，延迟很低，适合逻辑简单的数据处理 API。

认证和频率限制

每个用户生成一个唯一的 API Key。数据库里存好 Key 和用户的对应关系，每次请求时检查三件事：Key 是否有效、这个用户本月的用量有没有超过额度、调用频率有没有超过限制。

频率限制（Rate Limiting）从第一天就要加上，比如每分钟最多 100 次。没有它，一个写错了循环的用户就可能在几分钟内调用几十万次，由此产生的成本都要由你来承担。

动画：写错的循环让水龙头关不上，账单桶很快灌满溢出；装上限流阀之后水变成一滴一滴，到上限刻度时浮球把阀门关死

计费

Stripe 是海外开发者最常用的收款方式，它有专门的按用量计费功能：你每次处理完一个请求，就向 Stripe 上报一条用量记录，Stripe 会按月汇总、生成账单并扣款。

需要注意的是，Stripe 旧的 Usage Records 接口已经在 2025 年弃用，现在要用 Billing Meters，或者 Stripe 新推荐的 Metronome。网上很多早几年的教程还是用旧接口写的，照着做之前要先确认一下。

另外，Stripe 目前不支持中国大陆的主体直接注册。国内开发者常见的做法是注册香港等地的公司来开户，或者使用 Paddle 这类 MoR（Merchant of Record，代收款平台，它会作为卖方帮你收款并处理各国的税务），手续费更高一些，但省掉了自己处理海外税务的麻烦。

文档

对于 API 来说，文档就是产品界面。开发者看不懂文档，就不会用你的 API。Mintlify 是专门做 API 文档的工具，可以根据接口定义生成能直接在页面上测试的示例。

文档至少要包含：

快速开始：让开发者 5 分钟内跑通第一个请求
认证说明：怎么获取和使用 API Key
端点文档：端点（endpoint）就是一个具体的接口地址，每个端点要写清楚参数、返回格式和错误码
代码示例：至少给出 Python、JavaScript 和 curl 三种

开发者是怎么找到你的 API 的

GitHub 上的示例和 SDK

开源一个使用你 API 的 Demo 项目，或者发布一个 SDK（Software Development Kit，封装好 API 调用的代码库，让别人少写几行代码）。开发者更愿意相信能看到代码的 API，这也是目前成本最低、效果比较好的渠道。

写技术文章

写文章展示你的 API 能解决什么问题，比如“用这个 API，10 分钟给自己的产品加上链接预览”“自己实现截图服务和直接用 API 的对比”。这类文章容易被搜索引擎收录，开发者看完就可以直接注册试用，转化的路径很短。

开发者社区

Hacker News：用 Show HN 开头发帖，这是该站专门用来展示自己作品的格式
Reddit：r/webdev、r/programming，以及和你的 API 所在领域相关的子版块
国内社区：掘金、V2EX，以及各类开发者群

API 市场

市场的好处是有现成的开发者流量和计费系统，适合在冷启动阶段验证需求。但平台的用户并不是你的用户，平台随时可能把他们推荐给你的竞品，所以市场适合用来验证需求，不适合作为唯一的渠道。

Apify Store：爬虫和自动化类工具的主要市场，在 Apify 里这类工具叫 Actor。Apify 在 2025 年 11 月公布，商店里已经有 8,000 多个 Actor，2025 年 9 月一个月就给开发者分成了超过 56 万美元，累计已经超过 400 万美元。平台抽成 20%，你的 Actor 运行时产生的平台资源费用也会从收入里扣除。还有一个变化要注意：Apify 已经在 2026 年 10 月 1 日停用了按月租用的 rental 模式，现在只能按事件计费（pay-per-event）或按用量计费，之前看到的 rental 教程已经不适用了。
AWS Marketplace：面向企业客户，客单价高，但审核和合规的要求也高，适合已经有成熟产品和客户案例之后再上。
RapidAPI：曾经是最大的通用 API 市场，2024 年 11 月被诺基亚收购，之后重心转向了电信网络相关的 API。现在可以顺手挂上去，但不建议把它当成主要的获客渠道。
阿里云云市场：如果你的客户在国内，可以考虑上架阿里云云市场的 API 类目。不过入驻要先成为阿里云的生态合作伙伴，审核通过后还要缴纳 3 万元保证金，门槛比海外的市场高不少，更适合已经有公司主体、产品也比较成熟的团队。

整体来看，现在比较稳妥的顺序是先做 GitHub 和技术文章，再考虑上架市场。