发布说明

每月调用额度大幅提升

相比保留期限，大家对调用额度的需求要多得多。因此我们整理了数据保留策略，把这部分余力转到了额度上。Basic 和 Pro 都提升 3 倍以上。

• Basic 每月 30,000 次 → 100,000 次，Pro 300,000 次 → 1,000,000 次
• 生产记录至少保留 60 天（沙盒与此前一致，仍为 30 天）
• 使用统计照常保存，仪表盘图表保持不变
• 归档下载下线。保留期内的记录仍可在日志中查看
• 若要长期保存数据，请在记录到达时就取走 — 设置 Webhook，或通过 GET /api/v1/data/<your-slug>/poll 轮询

轮询有了专门的端点

想拿到新记录的客户端只能反复重读列表端点的第一页——按时间倒序，又没有办法指定"从什么时候开始"，所以每次轮询都会把同样的记录再取一遍，然后丢掉绝大部分。现在有了专用的轮询端点：只返回上次调用之后到达的数据，从旧到新，并且记住你读到了哪里。

• 新端点 GET /api/v1/data/<你的-slug>/poll — 上次调用之后创建的记录，从旧到新，每页最多 100 条
• 把上一次响应中的游标原样传回即可，无需自己管理时间戳。首次调用可以用 since（一律为 UTC），也可以什么都不传，即从那一刻起开始订阅
• 每次响应只会包含两种游标中的一种：next_cursor 表示还有积压，应立即再次调用；poll_cursor 表示已经追平，保存它并等到下一个周期
• 最近约 60 秒会在队列追平之前保留，所以记录是被延后到下一次轮询，而不是被跳过
• 重试和重启可能重复投递同一条记录，因此请按记录 id 做幂等处理
• API 参考、沙箱控制台代码示例和集成文档均已同步

Webhook 重试次数在所有页面统一了数法

此前不同文档对 Webhook 重试的数法不一致：有的只数重试次数，有的数总尝试次数，同一套策略在不同页面看起来像 5 次或 6 次。现在所有页面给出同一个数字。接收方约定也写清楚了当你这边的处理失败时该返回什么。

• 生产环境共 6 次尝试——首次投递 1 次 + 重试 5 次（30 秒·2 分·10 分·1 小时·4 小时）。沙箱环境约 12 分钟内共 4 次
• 2xx 表示"我收到了"，而不是"处理成功了"——即使你这边的处理失败也要返回它，并把该失败记录在你自己的系统里
• 5xx 只用于它真正表达的情况：你的接收端或它依赖的服务临时故障，稍后重新投递同一条记录有可能成功
• 日志页面的重试徽章现在显示 3/6 而不是 2/5——同一次投递，按文档的口径计数
• 投递与重试的行为没有任何变化，变的只是描述方式

Webhook 停止工作时，我们会发邮件通知你

投递中断的 Webhook 是无声的——数据照常保存，所以在你翻日志之前一切看起来都正常。现在，重试全部用尽时我们会告诉你。

• 邮件会写明是哪个端点、响应码与失败原因，以及接收服务器返回的响应正文——那是区分防火墙拦截与应用拒绝的唯一线索
• 一次抖动不会触发。它在我们放弃投递时发出——生产环境用尽重试约需 5 小时，若响应是不再重试的永久性错误则立即发出
• 无论失败多少次，每个端点每天最多一封。邮件里也会告诉你数据仍安全保存
• 免费套餐同样会收到。仅限生产环境的所有者 Webhook，协作者 Webhook 不在范围内，因为你无法更改那个 URL
• 没有恢复通知，也没有后续邮件——修好接收服务器，下一次调用即可正常送达

事件通知功能已移除

将 Webhook 投递失败、用量阈值等事件推送到 Discord、Slack 或 Telegram 的功能已移除。真正需要的提醒早已通过邮件发送，您无需做任何操作。

• 端点详情页的通知卡片已移除，AI 工具也不再接受通知设置
• 用量警告、超出上限、部署申请与完成的提醒仍然通过邮件发送 — 这部分没有变化

投递失败的 Webhook 现在会显示在日志中

日志页面此前只显示我们是否接收并保存了请求。即使 Webhook 从未送达你的服务器，也仍然显示为成功，数据可能悄悄丢失。现在投递失败会出现在同一个页面上。

• Webhook 列会标出投递失败或仍在重试的调用，并显示响应码
• Webhook 失败筛选可只看尚未送达你服务器的调用
• 日志详情会原样显示你的服务器返回的响应内容 — 这是区分防火墙拦截与应用拒绝的唯一线索
• 包括自动重试在内，每次尝试都会列出时间与耗时
• 只有失败的投递会被记录，因此空白并不代表成功；未配置 Webhook 的端点不会显示该列

每个 Webhook 都带签名了

此前区分真实 Webhook 与伪造请求的唯一手段是固定的认证请求头——设置是可选的、每次请求值都相同，而且无法察觉报文被篡改。现在每次投递都会附带 HMAC-SHA256 签名，你可以验证它。

• 签名遵循 Standard Webhooks 规范，9 种语言的官方库大约三行代码即可验证
• 验证是可选的——如果你已在接收 Webhook，在你启用之前不会有任何变化
• 密钥位于端点详情页的 Webhook 签名密钥，沙箱与生产环境各自独立
• 重新签发后旧密钥仍有效 24 小时，你可以在不丢失投递的情况下更新服务器
• 通过你自己的回调 URL 收到的 Webhook 同样带签名

Webhook 重试从秒级延长到小时级

过去 Webhook 重试被困在单次请求内，3 次尝试在 24 秒内就结束了，宕机的接收服务器几乎不可能在这个窗口内恢复。现在重试已迁移到队列。

• 超时从 7 秒延长到 15 秒
• 生产环境约 5 小时内重试 5 次；沙箱环境约 12 分钟内重试 3 次
• 新增 X-3minapi-Record-Id 头，在各次尝试中保持不变——请用它判断重复
• 除 429 外的 4xx 不再重试，包括 409——我们将其理解为"已收到"
• 失败的投递现在会被记录——将在后续版本中于日志页面显示

Google Sheets 集成已下线

为了专注于接收、存储和转发 API 数据这一核心能力，我们移除了 Google Sheets 集成。

• 现有电子表格仍保留在您的 Google Drive 中 — 没有任何内容被删除
• 所有 API 记录仍可在日志、统计和归档中查看
• 电子表格相关流程可通过归档的 CSV 导出替代
• 已释放 3Min API 此前获得的 Google Drive 权限

新增搜索 (Search) 端点

通过 payload 中的文本查找记录的全新 API 端点。

• 不区分大小写的部分匹配,最少 3 个字符
• 可指定时间范围 — 未指定时默认最近 30 天
• 游标分页(每页 1-30 条,默认 10 条)

WordPress 插件已上线(zip 安装)

在 WordPress 页面中无需代码即可构建输入表单与数据视图,并直接对接 3Min API。

• 以可下载的 zip 文件分发(手动安装)
• 自动生成表单/列表/单条记录视图代码片段

• 查看 WordPress 插件 →

新增列表 (List) 端点

不带 record_id 调用 GET 即可获取最近的记录列表。

• 按创建时间倒序
• 游标分页(每页 1-30 条,默认 10 条)

MCP 支持与 ChatGPT 插件上架

AI 智能体可使用自然语言直接调用您的 API。

• 为每个端点自动提供 MCP 服务器
• 支持 Claude / Cursor / ChatGPT 插件

• 在 ChatGPT 插件中搜索 "3Min API" →

正式上线

3Min API 正式向公众开放,提供免费/付费方案与指南文档。

封闭测试

以邀请制封闭测试启动,仅限受邀的早期用户使用。