Video API billing terms checklist: expiry, refunds, storage

Higgsfield's API post lists pay-as-you-go USD, no charge for failed requests, funds expiring in one year and files kept 7 days. A buyer checklist built on it.

4 min readSume
All posts

Before you wire a video API into production, check five billing terms: how you pay, whether failures are charged, what happens at zero balance, whether funds expire, and how long output files are kept. Higgsfield's API post, read 2026-10-03, states all five, so it makes a useful template.

What the Higgsfield post states

These items come from the vendor's September 16 post and are quoted as stated there.

Higgsfield API terms (read 2026-10-03)
TermWhat the post says
PaymentPay-as-you-go in USD
Failed requestsNot charged
Zero balanceSpending stops at zero
Funds expiryFunds expire in one year
File storageFiles stored for a minimum of 7 days
SDKs and catalogPython and TypeScript SDKs, 50+ models

The checklist

Ask each question of any provider, including Sume, and write the answers down before you sign off a budget.

  • Is balance reserved at submit or charged at completion? On Sume it is reserved at submit at provider list times 1.25.
  • What do you get when the balance is short? Sume returns 402 insufficient_credits.
  • What are the retry rules? Sume asks you to send an Idempotency-Key on every paid submit and to retry with the same key after provider_capacity_exceeded.
  • Do funds expire? Find the sentence in each provider's terms and quote it in your runbook rather than assuming.
  • How long are outputs retained? Treat any URL as temporary and copy the file into your own storage soon after completion.

What the Sume docs say about failure

The errors page lists job error categories such as validation, quota, queue and generation_unavailable, each with a next action. Add funds for quota, retry later with the same idempotency key for queue, and fix input for validation. Failed jobs expose a public error with retryability and a retry-after value where one applies.

The queue_full error is separate from ordinary rate limiting. It means the workspace has no room for another paid job until one finishes or is canceled.

Putting it in a runbook

Turn each answer into a line in your operations notes: who tops up the balance, at what threshold, and who gets an alert. A zero balance stops spending, which is safe, but it also stops production, so an alert before zero is worth more than a refund policy after it.

Review the notes when the vendor changes its terms. Billing terms change more often than model capabilities do.

Run the checklist once, then monitor

Put the answers in your runbook and check them again when the vendor posts a pricing change. On Sume, GET /v1/videos/models returns pricing_skus per model and the poll response carries usage.cost, so you can reconcile your invoice against each job instead of trusting a monthly total.

Sources

Related posts

More in Pricing

All Pricing posts

Written by Sume