Where did the Sume Credits page go? Billing & subscription top-up

The old Credits page is now Billing & subscription in the Sume dashboard: plan status, balance, Stripe top-ups. What the API can and cannot do.

5 min readSume
All posts

The Credits page is now called Billing & subscription, and it lives at dashboard/subscription: it shows your plan status and available balance and is where you buy credits for Developer API usage (read 2026-10-03). Older docs and tutorials still say 'Credits', which is the same surface under its previous name.

If you landed here because a script returned 402 insufficient_credits and you cannot find where to pay, the short route is: sign in, open Billing & subscription, check the balance, top up, and rerun the job with the same Idempotency-Key.

What the page does

According to the Billing and credits docs, the dashboard can start a Stripe-backed manual credit top-up when billing is configured for the workspace. After checkout completes, the usage ledger can show the top-up and the updated balance. The page also shows plan status, which matters because generation concurrency is set by plan, not by balance.

That last point surprises people. The generation admission docs state that concurrency is plan-only and that prepaid top-ups do not raise the processing concurrency limit. A bigger balance buys more generations in total, not more at the same time.

What the API can do

The public Developer API exposes two reads, GET /v1/balance and GET /v1/usage, scoped to the authenticated key's workspace. There is no public endpoint to create a top-up; the docs say API clients should treat top-ups as dashboard operations. Build your alerting around reading the balance and notifying a person, not around paying automatically.

Where each task lives, read 2026-10-03
TaskDashboardAPI
See plan and balanceDashboard: Billing & subscriptionGET /v1/balance
Review spendDashboard: UsageGET /v1/usage
Top upDashboard (Stripe checkout)Not available
Inspect a failed jobDashboard: JobsGET /v1/jobs/{id}

Avoiding the 402 in the first place

Check the balance before a batch and compare it with the planned cost. Twenty 30-second Plus clips need about $147.00 at the listed rate, so a balance below that will fail partway through. The error is returned before provider work starts, so provider work never starts, but you do lose time.

A simple rule of thumb is to keep a balance of at least twice the next planned batch, so retakes do not stall production. Set a reminder to review usage weekly rather than reacting to errors.

  • Read the balance, not a cached number.
  • Retry a 402 only after the top-up completes, with the same Idempotency-Key.
  • Do not create a second job for the same intent while the first is queued.

Checklist when a top-up does not show

These checks cover nearly all 'I paid but it still fails' reports, because the usual cause is a different workspace or key rather than a delayed payment.

  • Confirm the Stripe checkout completed rather than being closed early.
  • Reload the usage ledger, which can show the top-up activity and updated balance.
  • Make sure you are looking at the right workspace; balance is scoped to the workspace of the API key.
  • Check GET /v1/balance with the key your script uses, not a different key.
  • If billing is not configured for the workspace, the dashboard cannot start a top-up; ask your workspace admin.

Why the name changed

The dashboard rename reflects that the page now covers both subscription plans and the credit balance, with plan pricing on the public Pricing page and per-generation rates on the API pricing page. If you maintain internal documentation that says 'Credits page', update the link to dashboard/subscription and the name to Billing & subscription so new teammates are not sent hunting. The public API did not change: the balance and usage reads are still GET /v1/balance and GET /v1/usage.

Sources

Related posts

More in Pricing

All Pricing posts

Written by Sume