跳到主要内容

交易记录与花费

充值即将开放

支付宝充值即将开放；微信支付将在域名启用 HTTPS 后开放。开放之前暂时无法在线充值，如有疑问请联系 finance@superheat.cloud。

每一笔进出组织的余额都会写进一本只能追加的账本。控制台的账单页面用两种方式把它呈现出来：一张图表看花钱的形状，一张表格看背后确切的记录。

交易列表​

表格按从新到旧排列，一次显示 50 条记录；加载更多会取下一页。

列里面装的是什么
日期这条记录写入的时间，精确到秒
类型这是哪一类记录
详情对扣费记录来说，是它所属的实例和它覆盖的时长；其他记录见下文
金额余额的带符号变化，充值为正
余额这条记录之后紧接着的余额

你会遇到的类型：

类型控制台标签由什么产生
topup额度充值一笔已确认的支付宝或微信支付付款
charge_gpuGPU 使用运行时长，每个实例每个整点小时一行
charge_storage存储停止期间的磁盘时长，每个实例每个整点小时一行
adjustment调整由 Superheat CN 财务团队人工办理的退款或更正

退款不会自动发生。需要退款时由财务团队人工办理，并在账本里记一条 adjustment。支付宝或微信报告某笔已入账的付款被退款或关闭时，余额也不会被自动扣减：平台把它标记出来，由财务团队核对后处理。有疑问请写信到 finance@superheat.cloud。

财务团队通过 Superheat 的员工工具记入的调整带有 meta.reason staff_adjustment。这时它的类型显示为客服调整而不是调整，详情里显示他们写给你的备注。

对扣费记录来说，详情单元格会链到那个实例的账单标签页，并给出这一行覆盖的时长，例如 47 分 0 秒。仍在进行中的那个小时的记录会标为进行中。充值没有对应的实例，改为显示付款方式（通过支付宝、通过微信支付）。客服调整显示备注，其他调整显示一个短横线。

每个实例每小时一行​

费用仍然大约每分钟结算一次，和计费如何运作里说的完全一样，但不再每次结算各写一行。每个实例在当前整点小时里有一条开着的扣费记录，每分钟的结算都加到它上面：它的金额、覆盖的时长和它之后的余额一起增长，直到这一行关闭。出现以下情况时，这一行关闭，下一次结算开一行新的：

  • 这个整点小时结束；
  • 实例改变状态——停止、启动或销毁，会为到那一刻为止的时间单独写一行已关闭的记录；
  • 费率变了，或者实例换到了另一台机器；
  • 在它之后写入了一笔充值或调整。付款之后的余额永远不会被改写，所以一行不会越过它继续增长。

所以一个整天运行的实例大约产生 24 行，而不是 1,440 行；在一个小时中间停止，会让这一小时的记录提前结束。要看单个实例的合计，就打开那个实例读已结算支出；要看逐日的合计，就用图表。不满一分的金额会显示到小数点后四位，所以一笔小额存储费用读起来是 ¥0.0067（示例）之类的数字，而不是 ¥0.00。

支出图表​

支出——最近 30 天每天画一个点，30 天的合计就在标题旁边。把鼠标悬在某个点上，会给出那一天的数字。

图表统计的是什么：

  • 只有 GPU 费用和存储费用。充值和调整不计入——这是花费，不是现金流。
  • 天按你浏览器所在时区的日历日分桶——在中国大陆就是北京时间；浏览器报不出时区时，按 Asia/Shanghai。控制台把这个时区发给 API，由 API 按它分桶。
  • 没有费用的日子会画成零，而不是跳过，正是这一点让图表在几阵工作之间出现平直的一段段。

端点​

两个端点读的都是当前组织的账本。发送一个 bearer 令牌——可以是已登录的会话，也可以是 shk_ 组织 API 密钥。用会话时，由 X-Org-Id 选择组织，不带这个请求头就用个人组织；API 密钥被钉在它自己的组织上，为其他任何组织发送 X-Org-Id 都会被以 ORG_MISMATCH 拒绝。这两个端点都不要求管理员，所以成员或 API 密钥都能读。参见 身份验证。

GET /v1/billing/transactions​

curl "$SUPERHEAT_API/v1/billing/transactions?limit=100" \
  -H "Authorization: Bearer $SUPERHEAT_TOKEN" \
  -H "X-Org-Id: $ORG_ID"
参数取值范围默认值作用
limit1 到 20050每页的记录数
cursor一个记录 id—返回比这个 id 更早的记录
instance_id一个实例 id—把这一页限定在单个实例上

记录以从新到旧的顺序装在 items 里返回，旁边还有一个 next_cursor。把那个值作为 cursor 传回去就能取下一页；当它返回 null 时，你就到账本的尽头了。

每条记录都带着自己的 id（它同时充当分页游标）、type、所属的 instance_id（充值或调整则为 null）、created_at 时间戳、带符号的金额 amount_micro，以及由此得出的余额 balance_after_micro。金额以百万分之一元计：2290000 就是 ¥2.29。充值还带 provider（alipay 或 wechat），针对某笔订单记入的客服调整也带；调整有原因时带 meta.reason，例如 staff_adjustment，客服调整的 meta.note 就是详情里显示的备注。

计量类的扣费带一个 meta 对象，包含 period_start、period_end、seconds（这一行计费的时长）、rate_micro_per_hour 和 settlements（它累加了多少次每分钟结算；按小时成行之前写入的记录没有这个计数，每条就是一次结算）。它的 created_at 是第一次结算运行的时间，而且这一行只接收同一个整点小时里的结算。实例仍在往上累加的那一行 accruing 为 true：在它关闭之前，它的金额、meta.seconds、meta.period_end 和 meta.settlements 都会增长，它之后的余额、以及排在它后面的扣费记录之后的余额也会跟着变。其他每条记录一经写入就是最终的。如果你把账本复制到别处，请把 accruing 的记录反复重新读取，直到它变成 false。

要拉取单个实例的费用：

curl "$SUPERHEAT_API/v1/billing/transactions?instance_id=$INSTANCE_ID&limit=200" \
  -H "Authorization: Bearer $SUPERHEAT_TOKEN" \
  -H "X-Org-Id: $ORG_ID"

GET /v1/billing/spend-daily​

curl "$SUPERHEAT_API/v1/billing/spend-daily?days=90" \
  -H "Authorization: Bearer $SUPERHEAT_TOKEN" \
  -H "X-Org-Id: $ORG_ID"
参数取值范围默认值作用
days1 到 9030往前聚合多久
tzIANA 时区名，例如 Asia/ShanghaiUTC按哪个时区的日历日分组。API 不认识的名称返回 422 INVALID_TIME_ZONE

这就是图表的数据源：按 tz 的日历日分组的 GPU 和存储费用，从旧到新，每条记录带一个 date 和那一天的合计 spend_micro。不传 tz 时按 UTC 分组；想拿到和控制台一样的北京时间日期，请加上 tz=Asia/Shanghai。只有有费用的日子才会出现，所以清闲的一周产生的是没有记录，而不是一串零——如果你要画一条稠密的序列，空档得自己填。

相关内容​