跳转到主要内容
使用用户账单端点来读取团队的信用余额,并使用已保存的支付方式购买充值。这两个端点都需要使用你的 API 密钥进行身份验证。无效的密钥将返回 402。

检查信用余额

GET /user/credits/info 返回已认证团队的信用余额、每批次的详细信息、活跃的订阅详情,以及是否允许使用。 使用此端点为账单小部件、使用仪表板或在运行大型作业前进行预检。 有关 API 详细信息,请参见 获取信用信息。

响应

breakdown 中的每个批次都有一个 purchase_kind,可以是 Subscription、Top-up、Manual、Setup 或 Pending。

购买充值

POST /user/purchase-topup 使用 Stripe 上保存的卡片进行扣款并一步购买信用。没有结账重定向或嵌入的支付 UI。 在请求体中传递信用数量:
支持的值:10,000、20,000、80,000 和 100,000。 有关 API 详细信息,请参见 购买充值。

要求

  • 团队必须有一个 Stripe 客户,并至少保存了一张卡片。
  • 每个团队每 60 秒 只允许一次购买尝试。如果你触发了冷却时间,响应为 429,并带有 Retry-After 头。

响应

200 — 支付成功:
202 — 支付仍在处理中。信用将在 Stripe 确认支付后添加:
信用是在支付确认后由 Stripe webhook 发放的,而不是直接从 HTTP 响应中发放。将 200 视为支付成功;如果需要确认更新的余额,请轮询 GET /user/credits/info。

常见错误

自动充值

为了防止余额耗尽,定期检查余额,并在余额低于阈值时购买充值。这使用了上面的两个端点,并可以在任何可以运行脚本的地方工作:cron 作业、CI 步骤、无服务器函数,或在大型作业前的 AI 代理。
  1. 调用 GET /user/credits/info 并读取 credits。
  2. 如果 credits 低于你的阈值,调用 POST /user/purchase-topup 并传递支持的金额之一。
  3. 在 200 或 202 时停止。信用将在 Stripe 确认支付后到达,因此在下次检查前不要再次购买,直到余额更新。
使用 cron 每小时运行一次检查:
选择一个能覆盖检查间隔内使用量的阈值。如果你每小时运行一次检查,并且每小时使用大约 1,000 个信用,2,000 的阈值在充值处理中留有缓冲。
每次运行都可能会扣费。每个团队只运行一个充值作业,并通过等待下一个计划的检查来处理 429(purchase_topup_cooldown)和 503(payment_status_unknown),而不是立即重试。402(payment_failed)表示你的卡片被拒绝;在下次运行前在仪表板中更新它。