Skip to main content
Redeeming a credit code puts a pool of credits on your account, and those credits pay for your calls. You need no card while credits remain, and your keys work normally.

​
Redeem your code

  1. Sign in at cue.vibeset.ai. Your account is created on the first visit.
  2. Open Developer, find the Credits row of the Billing card, paste the code into the box (its placeholder reads CUE-XXXXX-XXXXX), and press Redeem.
  3. Create an API key under API keys. It works immediately.
Case, spaces and dashes do not matter. The server strips every non-alphanumeric character and upper-cases the rest before it looks the code up. An account may redeem one code. A second one is refused with a 409, so the box does not come back once you have redeemed. In its place the row shows your balance and expiry.

​
What a credit is worth

One credit is $0.001 of list-price usage. Credits are a denomination of the ordinary price list, not a second price table, so nothing is priced differently while you are on credits. Video and audio minutes both round up, with a one-minute floor. A call that errors bills nothing, and so does a loop that comes back applicable: false.

​
The high rate is not “once per track”

This is the number most integrations get wrong when they size a grant. Loop is strictly per pair. /v1/loop reads its plan cache on (video_id, track_source, track_key) and has no track-level fallback. Looping one track over ten videos is ten calls at 14 credits, not one at 14 and nine at 1. Budget the high rate for every new pairing, however many times you have used that track before. Sync is per pair with one escape hatch. /v1/align is warm when Cue already holds sync points for that exact pair, and also when it holds both profiles it would need to score them in memory: the video’s sync profile and the track’s audio profile. The audio profile is built the first time you align that track against anything, and the video’s profile is warmed in the background after ingest. That background warm is best-effort and swallows its own failures, so the video’s profile can be missing. When it is, the call is cold and bills 10 credits, even for a track you have aligned many times before. Do not budget sync as one cold call per track. Within one pairing the second call is warm either way. The first is not, and there is no way to pre-warm a pairing from the API.

​
Watching the balance

Three headers carry your position, and none of them is unconditional:
They are stamped on a /v1 response only when the request got past the key check and the account carries a grant. A 401 for a missing or invalid key carries none of them, and neither does any non-/v1 route. X-Cue-Credits-Expires needs one more condition: the grant must have an expiry. A grant minted with no expiry never sends that header, and its credits do not lapse. An unhandled 500 carries none of the three either, because the middleware that stamps them runs after the handler returns and never runs when the handler raises. Do not treat a missing header as a zero balance. The Credits row in the portal shows the same numbers, and the usage chart above it keeps working throughout a trial, because credit-funded calls are metered to the ledger at full list price. They are just not charged to a card.

​
When credits run out

Calls fail with 402 and a machine-readable prefix on the message:
If the ledger cannot be read, the call fails with 503 and Retry-After: 5 instead, and the message reads “Credit balance temporarily unavailable”. Retry it. Adding a video is refused before any analysis runs, so a video we did not process never costs you anything. The refusal lands on the video row rather than on the request, which returns 202 as usual. Poll GET /v1/videos/{video_id}:
reason is one of insufficient_credits, credits_expired, video_too_long_for_credits when the clip runs past the per-video ceiling on your grant (30 minutes unless we set it otherwise), or credits_unavailable when we could not read your balance. Only the last one is worth an immediate retry.

​
The monthly spend cap applies to credit-funded calls too

Credit-funded calls write their list price to the same usage ledger a paid call writes to, and the monthly spend cap reads that ledger. Accounts are provisioned with a 100cap.Spendinga100 cap. Spending a 100 grant inside one calendar month therefore also spends the cap, and the next call fails with a 402 naming the cap rather than the credits. Raise the cap under Billing in the developer console before a large batch.

​
Moving to paid

Add a card in Billing. Same keys, same endpoints, no re-integration.
Credits are used first. Adding a card while credits remain does not start charging you. Calls keep drawing on the grant and are not reported to Stripe until the credits are gone.

​
How many API keys you can hold

An account without an active payment method can hold two live API keys. Adding a card in Billing raises that to ten live API keys, and the change takes effect immediately — there is nothing to wait for and nobody to ask. A request past your limit is refused with a 409 naming the limit and how many keys you hold. Revoking a key frees its slot.
A key you rotated out stops counting as soon as its grace window closes. Rotating does not consume a slot.
Credits are not transferable between accounts, do not roll over, and are not refundable for cash. They stop when they are spent or when the window closes.