Two workspaces silently started returning 402 "Credit balance exhausted"

Support Help
1

Hi Retell team,

We run one Retell workspace per client. Two of them silently started returning HTTP 402 on every create-chat call, which took down the live chat assistants on both clients’ production websites. We were not notified in any way, and we only found out by debugging the outage ourselves.

We have already restored both workspaces by purchasing credits, so we are not asking you to restore anything. We are asking for notification, because we have other clients running live on pay-as-you-go and we cannot have their production chat go down silently again.

Affected workspaces

Aceites Piuqué
Org ID: org_DVXaHeIjNzskYfsT
Chat agent: agent_019efbf2f3b0d5072ade4ab0c1
Last successful create-chat: 2026-06-29 22:38 UTC

Conectar
Org ID: org_YB5z9UKJlDkQ1BxP
Chat agent: agent_14db9f1ab13bf1131df9ec666a
Last successful create-chat: 2026-07-16 15:54 UTC

What we saw

Every POST /create-chat returned:

HTTP 402
{“status”:“error”,“message”:“Credit balance exhausted, please top up to continue.”}

Read operations stayed healthy the whole time — GET /get-chat-agent, POST /v3/list-chats and GET /get-concurrency all returned 200 — so nothing surfaced as an account-level problem. Only chat creation was blocked, and it failed with no warning.

Why this hit us so hard

  1. Both workspaces were set up as pay-as-you-go. We did not switch either of them to a prepaid credit model.
  2. We received no notification of any kind — no email about a low balance, an exhausted balance, a billing-mode change, or a failed payment. We checked our inbox and there is nothing.
  3. Because the failure is server-side and silent, the outage lasted a long time before anyone noticed. Aceites Piuqué’s website assistant was down from approximately 2026-06-29 until today — close to two months of lost customer conversations for that client.

What we’re asking for

  1. Notify us before and when this happens. An email when a workspace’s balance is running low, and another when it reaches zero and API calls start being rejected. Right now a workspace can go from working to fully blocked with zero signal.
  2. Tell us the exact condition that triggers the 402, so we can reason about it. Were these workspaces moved off pay-as-you-go at some point, or does pay-as-you-go also require a positive credit balance to keep serving requests? We need to know which, because it changes how we set up every other client.
  3. Point us to a programmatic way to monitor it — an endpoint that exposes the current balance or billing state, or a webhook event we can subscribe to. We would much rather detect this ourselves than hear about it from a client whose website assistant has been dead for weeks.

Happy to provide request IDs, timestamps, or anything else that helps you trace it.

Thanks,
Steeve Martin
Virtual Solutions

2

Hello @steevemartin Thanks for sharing your Org ID. Let me check this with the team, and I’ll get back to you with an update.

3

Hello @steevemartin going in the order you asked.

**Billing model / were you moved off PAYG?**

  • No migration happened. Both workspaces were created on our current prepaid-credits model (V2) from day one; they were never on the legacy postpaid model.
  • On V2, metered endpoints (create-chat, create-web-call, phone calls) require a positive credit balance at request time. Non-metered reads bypass that check, which is why those kept working while create-chat 402’d.

**Exact 402 trigger**

  • Condition: available credit balance ≤ $0 on a V2 workspace.
  • Response: HTTP 402 with "Credit balance exhausted, please top up to continue."
  • It clears automatically as soon as a top-up settles.

**Notifications — honest answer**

  • We do have low-balance and zero-balance email templates in the billing service that fire off Stripe billing alerts to users with the billing-recipient permission on the workspace. For your two workspaces those emails did not go out, and I don’t want to hand you a definitive reason without confirming it — the two most likely causes we’re checking are (a) the Stripe billing alerts weren’t provisioned against these specific customers, so the webhook never fired, and (b) no user on the workspace held the billing-recipient role, so the recipient list was empty. I’ll come back with the specific cause and the fix on our side.
  • Either way, this is on us to make more robust — I’m surfacing to product/billing that the current mechanism is fragile and a first-party “balance is low / balance is zero” signal deserves better guarantees.

**Programmatic monitoring**

  • We don’t currently expose a public credit-balance endpoint or a credit.low / credit.exhausted webhook. I’m attaching that as a product ask alongside the notification issue.
  • Interim workaround that works today: run a scheduled synthetic create-chat against each workspace and alert on any 402 whose body matches "Credit balance exhausted". That’s the most reliable early-warning signal until we ship a real balance endpoint.
  • You’ve also now set Auto Recharge on both workspaces (threshold $10 / target $30), which will attempt an automatic top-up invoice when the balance drops under the threshold. I want to verify end-to-end that auto-reload charges cleanly given the default payment method on both Stripe customers is currently a Stripe Link entry rather than a standard card — I’ll confirm and get back to you before you rely on it as your only backstop.

Happy to keep this ticket open as the tracking thread for the notification investigation and the balance-endpoint ask.

Thank You