请求号与重复提交

以下四个接口必须传入 request_no：

• 购买动态流量；
• 创建动态子账号；
• 创建静态代理购买订单；
• 创建静态代理续费订单。

格式

request_no 长度为 1～64 个字符，只允许：

• 大小写英文字母 A-Z、a-z；
• 数字 0-9；
• 下划线 _；
• 连字符 -。

请求号区分大小写。建议使用业务类型、日期和调用方唯一序号组合，例如 static-buy-20260824-001。

使用边界

request_no 只用于防止同一次操作被重复受理。它不是结果查询键，不能用来直接取得第一次请求的结果；重复提交也不会重放第一次响应，更不保证重复请求得到相同的业务结果。

收到 300006 只表示该请求号在保护期内已经使用，不能据此判断第一次请求成功还是失败。

保护范围

相同账号、相同操作和相同 request_no 在 24 小时内只能提交一次。重复提交返回 300006。同一账号下的不同 API Key 共用这一保护范围；更换 API Key 不能绕过重复提交保护。

该机制用于拒绝重复受理，不会返回第一次请求的结果。第一次请求一旦进入处理，无论成功、失败还是调用方因网络超时未收到结果，请求号都会保留 24 小时，不会因重试而释放或延长。

保护期结束后，再次使用同一 request_no 会被视为新的操作，可能产生新的业务结果。建议为每一次新的业务操作生成从未使用过的请求号。

不确定结果处理

如果写请求发生超时、断连，或返回非 JSON、空响应等不确定结果：

1. 不要使用原 request_no 或新 request_no 盲目重新提交。
2. 先使用已有的列表、详情、余额、批次或资源状态查询接口核对结果。
3. request_no 本身不是查询条件，应结合调用方保存的请求内容、调用时间和已知业务信息进行匹配。
4. 暂时没有查到结果并不能证明第一次请求没有生效，应结合请求时间继续核对。
5. 如果仍无法唯一确认，联系客户支持，并提供 request_no、调用时间、环境和 X-TRACE-ID（如有）。绝不能提供 API Key。

调用方应将 request_no、请求内容、调用时间、环境、X-TRACE-ID 和已知的订单号一起保存，便于恢复和排查。