商店公开 API
面向程序的商店接口：目录、库存、余额与订单。密钥与私钥在个人中心自行创建，请求可以就地试跑——调试台直接从你的浏览器发出，密钥不会保存在服务器上。限额为每个接口每分钟 120 次、每个密钥 60 次，商店没有单独的 API 域名。所有请求都发往主域名。
https://boomly.ac/api/v1没有 api.* 子域名：基础路径是相对的 /api。
如何接入
X-API-Key: <ключ из личного кабинета>
X-Timestamp: 1785312000
X-Signature: hmac_sha256(secret, f'{ts}\n{body}').hex()频率上限
每个地址每分钟 120 次请求
并且不超过
每个密钥每分钟 60 次请求
密钥和密文由您在个人中心自行签发。仅对启用了签名的密钥才需要签名。
/v1/healthcurl https://boomly.ac/api/v1/health \ -H "X-API-Key: $KEY"
返回什么
{"status": "ok"}API 余额支付自动退款
通过 API 用余额支付的订单，如发货失败将自动退回余额。网站和机器人没有自动退款——那里不会扣款，出现问题时通过客服退款。
响应里替你做决定的那几个数字
每件商品的响应中都有两个不同的库存数字和两个不同的最低数量。混淆它们，是脚本下单失败或组装时间超出预期的最常见原因。
| 字段 | 含义 | 影响 |
|---|---|---|
| quantity | 该批次的总库存 | 橱窗「现货」一列显示的就是它 |
| instant_stock | 可从现成库存立即发出的数量 | 超出该数字的订单组装时间更长 |
| min_quantity | 供应商声明的最小批量 | 参考值 |
| min_qty_effective | 商店实际的最低数量 | 订单据此放行，数量步长也等于它 |
| sku | 商品的公开编号 | 商品页地址、重复采购、联系客服 |
| id | 内部编号 | 按 id 访问的链接会以永久重定向跳转到 sku |
规则很短：按即时库存与实际最低数量规划采购，引用时使用商品编号。总库存与供应商最低批量属于参考值；这些数字都不值得在两次运行之间缓存——目录是实时的。
订单：从请求到交付文本行
订单由商品编号与数量创建，随即获得自己的编号与状态。批次组装期间，状态会如实反映这一点；已完成的订单会在订单本身中返回交付的文本行——不需要再单独发一次取数据的请求。
- 数量应为该商品实际最低数量的整数倍，而不是供应商声明值的整数倍。
- 付款从余额扣除，因此交付无需等待转账确认。
- 通过 API 以余额支付的订单，若交付失败会自动退回余额。网站与机器人并非如此：那里只是不扣款，具体情况由客服处理。
同一笔订单在个人中心同样可见：交付内容可以再次复制或下载为文件，也可按单件商品分别下载。商店不发送邮件通知——它没有邮箱。
验收由脚本下单的批次
自动采购并不取消验收，而是加快验收。替换窗口为交付后 30 分钟；对脚本而言，这意味着核对必须在同一次运行中完成，而不是等到第二天早上。
- 把交付到的行数与下单数量核对一致。
- 检查字段构成：批次格式写在商品名称中，它决定了本来应该收到什么。站内的格式转换器可以把文本行拆成字段。
- 检查结束前不要修改密码、邮箱和绑定信息——任何此类改动之后保障即失效。
- 若未能在时限内完成，或构成对不上，请携订单号与商品编号联系支持机器人。
与手工验收相比，这里只有一点不同：核对由代码完成，而是否替换仍由支持机器人中的真人决定。因此在采购脚本里最好把订单号与商品编号与核对结果一并保存——这一对信息会被第一个问到。
两个辅助接口：可用性与密钥用量
有两个接口值得从第一天起就纳入监控。其一回答「地址是否还活着」，除请求本身不需要任何东西——用它可以区分「商店无响应」与「密钥已被吊销」。其二显示该密钥当天已消耗多少次请求，以及它每分钟的上限。
限额数值标注在上方卡片中，并且独立计算：一个针对接口，另一个针对密钥。用量接口的意义在于提前看到接近上限：在采购时刻被限额拒绝，代价高于请求之间多等一会儿。
问答
常用页面