短信验证 API

1. GET /api/v2/tn101/get-services——服务目录，包含下单时使用的标识符及其当前价格。
2. POST /api/v2/tn101/request-number——下单一个号码。参数为 service_key，以及可选的 state 和区号。返回订单 ID、号码及其到期时间。
3. GET /api/v2/tn101/get-number-details——使用 order_id 轮询。验证码到达前 pin 为 null，到达后即包含验证码。这是 API 中开销最小的读取接口，也是专为循环调用而设计的接口。
4. POST /api/v2/tn101/reject-number——释放一个什么都没收到的号码。退回费用也是通过这一步完成的。

这条路径上不会主动向你推送任何内容，所以第 3 步是轮询。如果你更希望被通知而不是主动查询，账户还支持在订单事件发生时发送 Webhook，可在控制面板中配置。

每个请求都需携带 Authorization: Bearer <token>。令牌在控制面板的 API 访问页面生成，并可随时在那里轮换——轮换会立即使旧令牌失效，所以请先在你的配置中替换好。

没有有效令牌的请求返回 401。账户被停用或 API 访问被关闭时返回 403。当 API 在全站范围内被禁用时，所有接口都会如实返回 503。

每个接口都返回相同的三个字段：

data 承载数据内容，success 是用于分支判断的布尔值，summery 是人类可读的消息。这个拼写并不是本页的笔误——这是 API 一直以来使用的字段名，所有基于它编写的集成中都有它，为了改正一个字母而重命名，会让所有集成全部失效。请读取 summery。

参数校验失败时返回 422，此时 data 是一个由字段名映射到错误信息的对象，调用方因此可以报告具体是哪个参数出错，而不仅仅是“出错了”。

用 API 来测试注册或找回密码流程非常实用，走的是真实的运营商链路而不是模拟环境——下单号码，用它驱动你自己的表单，轮询验证码，再断言你的应用接下来的行为。它比桩测试慢，但能发现桩测试发现不了的问题：号码规范化、线路类型过滤，以及你的用户实际会遇到的送达延迟。

API 没有每秒请求数限制，但下单有两项配额，与控制面板执行的完全相同：

• 未完成订单数。 一个账户同时能持有的预留号码数量有限。请轮询并释放号码，而不是同时大量开单。
• 每日取消和过期订单数。 超出每日额度后，下单功能会暂停一段时间，重复超出则暂停时间递增。无论验证码是否到达，每次预留都会消耗真实的号码资源，配额保护的正是这一点。

这两项配额在临时号码一页有更详细的说明，那里也介绍了订单的完整流程。