An HTTP 402 during a prepaid API session

You send a prompt from a coding tool or a small application, expecting an answer. Instead, the request returns HTTP 402. The message may say “Payment Required,” even though you already added an API key and your setup worked earlier.

On a prepaid API, this usually points to an account funding issue. It does not, by itself, mean your prompt is invalid or your integration needs rebuilding. The useful next step is to read the error message and check the account behind the key.

§ What HTTP 402 tells you

HTTP status codes describe the result of a request. A successful API call commonly returns 200. A 402 response is labeled Payment Required. Its exact meaning depends on the service, so the accompanying error message matters.

For a prepaid service, the usual explanation is that the available balance cannot cover the request. Your account might have run out of credit, or the service might require enough available credit before accepting work. A positive balance therefore does not always establish that a particular request can proceed.

Vana API bills for real token usage with no monthly fee. That makes the available prepaid balance relevant to continued use. Having a working API key and having enough credit are separate conditions.

§ Check the account before changing the code

Start with a few checks that do not require editing your application:

• Read the response body. Look for an explanation alongside the status code. A tool may show only a short summary; its error details or logs may contain more.
• Check your available balance. Open the account associated with the API key used by the failing application.
• Confirm any recent payment. If you just added funds, check whether the payment completed and whether the balance reflects it before paying again.
• Check which key the tool actually uses. A terminal session, editor, and deployed application can each load different credentials.

Avoid replacing keys or changing model settings at random. Those changes can introduce another problem while leaving the funding issue unresolved.

§ Retry after the cause is resolved

If the error confirms insufficient credit, add funds through the service’s account interface. Once the balance is available, send one small test request. A short prompt with a modest output limit makes it easier to confirm that requests are working again.

Repeated automatic retries will not replenish a balance. If your application retries every failed request, make a payment-related 402 pause that behavior and show a clear message to the person managing the account. Keep it distinct from temporary connection failures that may benefit from retrying.

In a coding assistant, also check the conversation before resuming a larger task. The tool may have completed earlier steps before the failed request. Review its current state so you can continue from the right place.

§ Understand what uses the balance

A short message on screen can still produce a substantial API request. Tools may include conversation history, source files, instructions, and other context. Both the material sent to the model and the generated response can affect token charges, according to the model’s pricing.

For example, a session using Claude Sonnet 5.5 can accumulate usage across several calls as the assistant reads files and answers follow-up questions. Check usage records alongside the balance to understand the pattern. Starting a fresh conversation when old context is unnecessary, limiting output, and choosing a suitable model can help control spending.

§ When the balance looks sufficient

If 402 continues, save the error text, approximate time, requested model, and request identifier if one is provided. Contact support with those details. Never include your full API key. This gives support something concrete to investigate without exposing credentials.

If you are setting up a prepaid workflow for the first time, create a Vana API account and begin with a small test through your preferred client. Vana API supports OpenAI-compatible requests, Anthropic Messages, and Gemini native protocols at one endpoint. Whichever client you use, treat HTTP 402 as a reason to inspect payment status before sending the same request again.