STOP WASTING PAID TOKENS. START POOLING ACCOUNTS TODAY. [ GET YOUR VAULT ]

Bring a failed key back

Who this is for: Anyone whose provider key has stopped working — the contributor who added it, or the brand admin who was told about it in the daily digest.

What this does: Returns a disabled credential to the routing pool by re-authenticating it in place, keeping its key id, sharing settings, limits and history.

Before you begin

  • The key has failed. SpiderGate has already stopped routing to it, so your agents are being served by the rest of the pool. A healthy key needs nothing done to it.

  • You have the replacement secret to hand, or you can log in to the provider account. Re-authentication needs one or the other; it cannot revive a key on its own.

  • If you are an admin rather than the person who added the key, the daily digest names the contributor to chase. Only they receive the emailed link.

Steps

  1. Open the re-authentication link you were emailed. The contributor who added the key is sent one automatically, up to three times, 48 hours apart, and never inside their quiet hours. The link is valid for 120 hours.

  2. Read the reason shown at the top of the page. It tells you whether the credential expired, was revoked, or simply failed too many times in a row — which decides whether a fresh secret will help.

  3. Supply the credential. For a pasted-key provider, enter a fresh key. For an OAuth or subscription provider, click through the re-login instead — there is no key to paste, and the page routes you to the correct flow automatically.

  4. For an OAuth key you can also start the same flow from the dashboard: open Dashboard → Vault, hover the key's row, and choose Re-auth. This action appears for OAuth credentials only; a pasted-key credential is recovered through the emailed link.

Verify it worked

The credential is active again and its failure count has reset to zero. Confirm it is genuinely serving rather than merely marked healthy: send a request that uses the key's provider and open the trace. The trace names the model that actually answered, so you can see the request served by the recovered key rather than falling through to a fallback. If you have no test request handy, the key's quota meter ticking up is the same evidence.

Troubleshoot

The link says it has expired. Links last 120 hours, which outlasts the full reminder cycle, so this usually means the key failed some time ago. The expired-link page has a Request a new link button that emails a fresh one to the contributor on record. You do not need an admin.

I never got an email. Three things stop one arriving: the key is degraded rather than unhealthy, so nothing has fired yet; there is no contributor email on record for the key, in which case it appears in the admin digest instead; or you are an admin, who receives the once-daily digest rather than per-key mail.

I re-authenticated and it failed again immediately. The new credential is being rejected by the provider too. Check that you pasted a key from the right account, and that the account itself is still active and in credit — re-authentication replaces the secret, not the subscription behind it.

The key recovered on its own before I did anything. That is expected. A key that has been unhealthy for 20 minutes with no authentication errors is returned to the pool automatically, because rate limits and timeouts heal by themselves. Only genuinely dead credentials wait for a person.

It keeps failing every few hours. A key that repeatedly fails authentication is deactivated for good after three such failures in 24 hours, precisely so it stops cycling. If you are seeing a cycle, the key is on its way to that state; replace the secret rather than resetting its health.

Related