更新日志

v3.2: 全新的订单系统：统一的错误列表、更简单的细水长流、更清晰的取消与补充

以下所有内容在 X-NotPanel-API-Version: 2026-10 响应头下一并发布。所有早期操作仍可使用，/api/v1、/api/v2 和 /api/v3 地址的行为完全相同。

• 每个订单只有一个编号，在控制面板、客服和 API 中通用。API 订单保留其原有编号。
• 细水长流：runs 加 interval 仍然可用。新的简单形式使用总 quantity 和 drip_feed_total_minutes，最长 48 小时。
• 最初 15 秒内取消是即时的，并全额退款。之后，在服务支持的情况下可以申请取消，并自动退款。order 像以前一样返回一个对象；orders 返回数组。
• 补充对每个订单每 6 小时可用一次，没有截止日期，被拒绝时会给出明确的原因。
• Telegram 反应是单一的 reactions 字段，可以是混合（👍,❤️,🔥），也可以是精确数量（👍:60,❤️:40），并在扣费之前检查。
• 服务列表显示标签、带限制的额外字段、细水长流限制和可用性。cancel: true 现在表示取消请求确实可用。
• 每个错误都有固定的错误码、HTTP 状态和 retryable 标志。早期错误码和当前错误码列在下方。
• 新增 order_details，它也可以通过你的 request_id 查找订单。
• status 已包含退款：对于已取消或部分完成的订单，refund 就是已退款金额，无需单独调用。refund_quote 是旧名称，返回与 status 相同的响应。
• Webhook 现在是统一的系统：每次调用一个签名事件，带版本，并为已取消和部分完成的订单以及补充结果提供新事件。
• 已移除：批量 webhook 正文、coupon 参数，以及 status 中的 refund_pending 字段和两个退款政策字段。旧的 delay 参数不再被读取；请使用 drip_feed_total_minutes。
• 已新增：status 中的 can_cancel 和 add 响应中的 instant_cancel_until。原有的 cancel_available 在两处都保留，cancel_window_seconds 和 cancel_before 保留在 add 响应中。
• 保留：catalog 和 account_status 操作像以前一样继续可用，catalog 现在记录在列出服务中。旧的参数名仍然有效：referer、lpost_count、用于话题标签列表的 hashtag、以逗号分隔的 usernames 以及旧的表情回应映射。webhook.add 也接受事件名 order.refunded 和 order.refill_completed。
• /api/v1、/api/v2 和 /api/v3 都继续可用，行为相同。文档记录的是 /api/v3。
• 已完成的订单始终将 remains 显示为 0。

v3.1: 符合市场习惯的可选服务名称

services 和 catalog 操作现在可接收可选语言代码，以返回十种受支持语言中采用精选的市场术语整理的服务名称。显式请求会加入规范名称和实际语言元数据；译名缺失或过期时会安全回退到英文。未传入 language 时，旧版英文响应结构保持不变。管理员可以审核或细化每个名称。

v3.0: v3 成为默认 API

/api/v3 成为规范端点，也是熟悉 reseller 契约的基础 URL 直接替代。v3 新增可选精确键、60 秒旧客户端保护、高级目录、数字 ID、refund_quote、account_status、单个或顺序批量取消以及签名 webhook。API 吞吐量现在由 lifetime successful spend 等级决定，并使用账户全部密钥共享的单个 60 秒滚动窗口。/api/v1 和 /api/v2 是当前同一契约的完全别名。

v2.5: 高级目录、退款对账与取消

新增分页 catalog 和只读 refund_quote 操作，扩展 add 和 status 元数据，并为普通 API 订单增加 15 秒取消窗口。API Webhook 事件现在携带稳定的事件 id；同一批次重试时 deliveryId 保持不变，而每次重试都会获得新的时间戳和签名。Webhook 仍会尽力投递并重试，但不保证持久的至少一次投递。

v2.4: 目录新增 12 个媒体平台

新增了 Google、Rumble、Audiomack、Tumblr、Kwai、Clubhouse、Vimeo、Deezer、Tidal、Apple Music、Quora 和 GitHub 的服务。它们会像其他服务一样出现在 services action 中，并各自拥有一个专属的公开平台页面。无需改动客户端——新的服务 ID 会直接出现在目录中。

v2.3: 下单时强制检查服务可用性

不可用服务会拒绝 action=add，而不会静默接受或排队新订单。请刷新目录并选择可用服务后再重试。

v2.2: 可选的下单参数

add action 现在接受受支持的、与服务类型相关的可选字段，例如启动延迟和按类型区分的互动选项。服务类型已定义的字段继续沿用其文档含义。

v2.1: 下单时的细水长流参数

对于 dripfeed=true 的服务，add action 接受成对使用的 runs 和 interval。总交付量为 quantity × runs，且不得超过服务上限。非滴灌服务会拒绝这两个字段。