# API收费适合个人开发者吗？

URL: https://caijiao.org/posts/223
Source: docs/posts/223.md
Description: Data Fetcher 一个人、600 个付费客户、23000 美元 MRR，收的是席位钱而不是调用次数。自己做按量计费，多出来的不是一个价格表，是一套要 7×24 小时对的账。

接口收费这件事，难的部分从来不是定价页面怎么写，而是每一次调用要在哪一毫秒被记下来。

很多人的设想是：给自己的小工具加个 API，按调用次数卖，一万个请求几美元，比卖会员优雅。我做过一次，最后把定价页撤了——不是没人买，是发现这套模式要求我同时运营三个我没能力运营的东西：计数器、配额系统、和一套解释"为什么这个月账单多了两美元"的客服流程。

## Data Fetcher 收的是席位钱，不是调用钱

Andy Cloak 的 Data Fetcher 是个 Airtable 扩展，用来把外部数据拉进表格。它的公开数据是：MRR 23000 美元，600 个付费客户，他一个人在伦敦运营。

![Data Fetcher 官网首页截图](/images/2026-09/datafetcher.com.jpg)

*Data Fetcher 首页写明 Connect any API to Airtable, without code，目标用户就是 Airtable 用户。*

23000 除以 600，客单价大约 38 美元一个月。这个价格对应的是"一个工作区/席位可以用"，不是"这一次请求多少钱"。

这个区别决定工作量。按席位收费，账单一个月生成一次，客户数量级是几百行记录，出错了退回去重生成就行。按调用次数收费，账单粒度细到每一次 HTTP 请求，一旦计数漏了一半，你要解释的不是"少收了钱"，而是"为什么上个月的账单是错的"。

一个人运营，容错空间本来就薄。选不需要解释每一笔的模式，本质是给自己留睡觉的时间——精确账单额外要求的是对账、解释和纠纷处理，而这三样恰恰最难自动化。

## 用量要记在哪：SQLite 够用，但要知道边界

如果确实要做按量，最小可行的账本其实不复杂：一张调用记录表、一张客户余额表，用 [SQLite](/sqlite/) 就能跑起来。

具体做法是把每个 API Key 的每次调用写成一行，包含时间戳和消耗单位，月底按 key 聚合出账。SQLite 单文件的好处在这里非常实在——备份就是复制文件，没有额外的数据库进程要维护，配合 cron 每天导出一次就够。

它的边界也很清楚：写并发。SQLite 在同一时刻只允许一个写事务，如果你的接口量上来，多个请求同时写这张表，会出现 "database is locked" 的报错。解决办法通常是把写入排队、在应用层做异步落盘，或者在这个节点迁到 PostgreSQL。这个迁移点值得提前想好——因为出问题的时刻，通常是你正忙于别的事的时刻。

计费单位的选择也值得早点想清楚。按请求数最简单，但最好被绕过——用户一个循环就能刷满；按返回结果条数更贴近真实价值，代价是要在业务代码里埋点；按运行时长计几乎必然要出纠纷。对个人开发者来说，最省心的组合通常是"固定额度 + 超额硬拦"，把精确的分层计费留到以后再说。

## 配额和限流，别写进业务代码里

接口收费有个绕不开的动作：超额要挡住。这里最容易犯的错是把限流逻辑写进自己的应用代码，于是每次调限额都要改代码、重新打包、重新部署。

更省事的做法是让边缘那一层去做。用 [Nginx](/nginx/) 配置限流区，按 IP 或按 API Key 限制单位时间请求数，超额直接返回 429，业务代码完全不知道发生过什么。改配额是改配置文件，reload 生效，不涉及发版。

这一层还能顺手解决另一个问题：把 /v1/ 路径反代到应用容器，静态站点继续由 Nginx 直接返回文件。你的 API 服务和工具页面就此分成了两个进程，谁崩了不会带走另一个。容器怎么起、数据卷怎么挂、日志往哪落，[Docker](/docker/) 那一栏里有完整的例子。

分工定下来之后还有一件小事别忘：给接口单独配置超时和重试策略。超时在 Nginx 这一层配好之后，后端就可以假设"请求会在合理时间内结束"，业务代码里那些到处写的兜底逻辑能删掉一大半——对个人开发者来说，少维护的代码就是少维护的风险。

## 一次买断不等于没有后续成本

不按量收费，还有别的路。Max Schmitt 的 Cakedesk 是 Electron + React + Node.js 写的桌面开票应用，卖一次性 69 欧元，没有订阅。2024 年卖出约 170 份，2025 年 239 份新授权，毛收入约 16000 欧元。

这里有个容易被算漏的地方：一次买断省掉的是计费系统，没省掉维护。Max Schmitt 在 2025 年一共发了 12 个版本，收到的 44 个功能请求里只完成 13 个。换算一下，每卖出一份授权，背后要摊掉一年份的 Electron 升级、依赖更新和邮件答疑——这些时间不会体现在收款流水里，但会真实地从开发时间里扣掉。

而且桌面应用在技术上本就不适合按调用收费：程序跑在用户本机，你没有一个可靠的计数端点。硬加用量统计就得要求联网校验，那等于把离线可用性卖掉了——而离线可用恰恰是用户愿意买桌面软件的理由。

而对纯 Web 的工具站来说，TinyWow 走的是另一条路——250 多个免费工具加上每月 5.99 美元的 Pro。$5.99 这种低客单价，恰恰是因为它不需要向用户解释用量：不限次本身就简化了整个计费系统。

给 API 定价之前，先问自己愿不愿意维护一个永远不能出错的计数器。愿意，再去设计阶梯价格；不愿意，就按席位或者干脆一次买断，把精力放回工具本身。

---

*Data Fetcher 数据来自 Andy Cloak 的公开分享；Cakedesk 数据来自 Max Schmitt 2025 年度自述；TinyWow Pro 定价引自其官网。*