Transactions and spend
支付宝 (Alipay) top-ups open soon, and 微信支付 (WeChat Pay) follows once the domain moves to HTTPS. Until then you cannot top up online; write to finance@superheat.cloud with any questions.
Every credit that enters or leaves an organization is written to an append-only ledger. The console's Billing (账单) page renders it two ways: a chart for the shape of your spending, and a table for the exact entries behind it.
The transaction list
The table is ordered newest first and shows 50 entries at a time; Load more fetches the next page.
| Column | What it holds |
|---|---|
| Date | When the entry was written, to the second |
| Type | What kind of entry it is |
| Detail | For a charge, the instance it belongs to and how long it covers; for other entries, see below |
| Amount | The signed change to the balance, positive for credits added |
| Balance | The balance immediately after this entry |
Types you will see:
| Type | Console label | What produced it |
|---|---|---|
topup | Credits added (额度充值) | A confirmed 支付宝 (Alipay) or 微信支付 (WeChat Pay) payment |
charge_gpu | GPU usage | Running time, one row per instance per clock hour |
charge_storage | Storage | Stopped disk time, one row per instance per clock hour |
adjustment | Adjustment | A refund or correction made by hand by the Superheat CN finance team |
Refunds never happen automatically. When one is due, the finance team makes it by hand and posts an adjustment to the ledger. When 支付宝 or 微信支付 reports that a payment already credited was refunded or closed, the balance is not debited automatically either: the platform flags it, and the finance team reviews it. Write to finance@superheat.cloud with any questions.
An adjustment the finance team posts through Superheat's staff tools carries meta.reason staff_adjustment. Its Type then reads Support adjustment (客服调整) instead of Adjustment, and its Detail shows the note they wrote for you.
For a charge, the Detail cell links to that instance's Billing tab and gives the time the row covers, such as 47m 0s (47 分 0 秒 in the 简体中文 console). The row for the hour that is still running is marked in progress (进行中). Top-ups have no instance and name the payment method instead (via Alipay, via WeChat Pay — 通过支付宝, 通过微信支付 in the 简体中文 console). A support adjustment shows the note; any other adjustment shows a dash.
One row per instance per hour
Charges are still settled about once a minute, exactly as How billing works describes, but they no longer land in a row each. Each instance has one open charge row for the current clock hour, and each minute's settlement is added to it: its amount, the time it covers and the balance after it grow until the row closes. A row closes, and the next settlement opens a new one, when:
- the clock hour ends;
- the instance changes state — a stop, a start, or a destroy writes a closed row of its own for the time up to that moment;
- the rate changes, or the instance moves to another machine;
- a top-up or an adjustment is written after it. A payment's balance is never rewritten, so a row never grows past one.
So an instance that runs all day produces about 24 rows, not 1,440, and a stop in the middle of an hour ends that hour's row early. For a per-instance total, open the instance and read Settled spend, and for a day-by-day total use the chart. Amounts under one 分 are shown to four decimal places, so a small storage charge reads as something like ¥0.0067 (illustrative) rather than ¥0.00.
The spend chart
Spend — last 30 days plots one point per day, with the 30-day total beside the heading. Hovering a point gives that day's figure.
What the chart counts:
- GPU charges and storage charges only. Top-ups and adjustments are excluded — this is spending, not cash flow.
- Days are calendar days in your browser's time zone — Beijing time in mainland China; when the browser names no zone, Asia/Shanghai. The console sends that zone to the API, which buckets the charges by it.
- Days with no charges are plotted as zero rather than skipped, which is what gives the chart its flat stretches between bursts of work.
The endpoints
Both endpoints read the current organization's ledger. Send a bearer token — a signed-in session or an shk_ organization API key. With a session, X-Org-Id selects the organization, and without that header the personal organization is used; an API key is pinned to its own organization, and sending an X-Org-Id for any other one is rejected with ORG_MISMATCH. Neither endpoint requires admin, so a member or an API key can read them. See Authentication.
GET /v1/billing/transactions
curl "$SUPERHEAT_API/v1/billing/transactions?limit=100" \
-H "Authorization: Bearer $SUPERHEAT_TOKEN" \
-H "X-Org-Id: $ORG_ID"
| Parameter | Range | Default | Effect |
|---|---|---|---|
limit | 1 to 200 | 50 | Entries per page |
cursor | an entry id | — | Returns entries older than this id |
instance_id | an instance id | — | Restricts the page to one instance |
Entries come back newest first in items, alongside a next_cursor. Pass that value as cursor to get the next page; when it comes back null, you have reached the end of the ledger.
Each entry carries its id (which doubles as the pagination cursor), its type, the instance_id it belongs to or null for a top-up or an adjustment, a created_at timestamp, its signed amount amount_micro, and the balance that resulted from it, balance_after_micro. Amounts count millionths of a yuan: 2290000 is ¥2.29. A top-up also carries provider (alipay or wechat), and so does a support adjustment posted against an order; an adjustment carries meta.reason when it has one, such as staff_adjustment, and a support adjustment's meta.note is the note the Detail cell shows.
A metered charge carries a meta object with period_start, period_end, seconds (the time the row bills), rate_micro_per_hour and settlements (how many minute settlements it adds up; rows written before hourly rows carry no count and are one settlement each). Its created_at is when its first settlement ran, and the row only takes settlements from that same clock hour. accruing is true on the row an instance is still adding to: until it closes, its amount, meta.seconds, meta.period_end and meta.settlements grow, and so does the balance after it and after any charge rows that follow it. Every other entry is final as written. If you copy the ledger elsewhere, re-read rows that were accruing until they come back false.
To pull the charges for one instance:
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"
| Parameter | Range | Default | Effect |
|---|---|---|---|
days | 1 to 90 | 30 | How far back to aggregate |
tz | an IANA time zone name, such as Asia/Shanghai | UTC | Whose calendar days the charges are grouped by. A name the API does not know returns 422 INVALID_TIME_ZONE |
This is the chart's data source: GPU and storage charges grouped by calendar day in tz, oldest first, each entry carrying a date and that day's total, spend_micro. Without tz the days are UTC days; add tz=Asia/Shanghai to get the Beijing dates the console shows. Only days that had charges appear, so a quiet week produces no entries rather than a run of zeros — fill the gaps yourself if you are plotting a dense series.