decolua/9router · error · Error

`Kimchi token validation failed

Error message

`Kimchi token validation failed: ${validationRes.status}`

What it means

Thrown when the Kimchi provider's token validation request — a GET to the CAST AI supported-providers endpoint (config.validationUrl) with the token as Bearer — returns a non-2xx status. The HTTP status is embedded in the message (e.g. 401, 403). This proves the token was present but rejected or the endpoint was unavailable.

Solutions

Read the status in the message: 401/403 → generate a fresh CAST AI API token with correct permissions and retry.
Verify the token works directly: curl -H "Authorization: Bearer <token>" https://api.cast.ai/v1/llm/openai/supported-providers.
If a custom config.validationUrl is set, confirm it is the correct CAST AI validation endpoint and reachable.
Check network/proxy settings if the status is 5xx.

Example fix

// before
validationUrl: 'https://api.cast.ai/v1/wrong-endpoint'
// after
validationUrl: 'https://api.cast.ai/v1/llm/openai/supported-providers'

Defensive patterns

Strategy: try-catch

Try / catch

try {
  await provider.exchangeToken(config, token);
} catch (e) {
  const m = e.message.match(/Kimchi token validation failed: (\d+)/);
  if (m) {
    const status = Number(m[1]);
    if (status === 401 || status === 403) {
      // prompt user to regenerate the CAST AI token
    } else {
      // transient/network issue: back off and retry
    }
  } else throw e;
}

Prevention

Pre-validate tokens with a direct curl against the supported-providers endpoint before saving them.
Track token creation dates and prompt rotation before expiry.
Keep config.validationUrl on the official CAST AI endpoint unless you truly need an override.
Surface the HTTP status from the message to the user to distinguish 401/403 from 5xx.

When it happens

Trigger: exchangeToken reaches the fetch and validationRes.ok is false: expired/revoked CAST AI token (401), token lacking required scopes (403), malformed token, network/proxy returning 5xx, or a custom validationUrl pointing at the wrong endpoint.

Common situations: Token copied from the wrong CAST AI org/API key; token rotated elsewhere after paste; corporate proxy intercepting api.cast.ai; typo in config.validationUrl override.

Related errors

AI-assisted analysis of decolua/9router@90b52e06ff (2026-08-30). Data as JSON: /api/errors/21a271f4751cfca7. Report an issue: GitHub.

Appendix: source

Thrown at src/lib/oauth/providers/kimchi.js:29

    });
    return `${baseUrl}/cli-auth?${params.toString()}`;
  },
  exchangeToken: async (config, token) => {
    const accessToken = String(token || "").trim();
    if (!accessToken) {
      throw new Error("Missing Kimchi token");
    }

    const validationUrl = config.validationUrl || "https://api.cast.ai/v1/llm/openai/supported-providers";
    const validationRes = await fetch(validationUrl, {
      method: "GET",
      headers: {
        Accept: "application/json",
        Authorization: `Bearer ${accessToken}`,
      },
    });
    if (!validationRes.ok) {
      throw new Error(`Kimchi token validation failed: ${validationRes.status}`);
    }

    let userInfo = {};
    if (config.userInfoUrl) {
      try {
        const userRes = await fetch(config.userInfoUrl, {
          method: "GET",
          headers: {
            Accept: "application/json",
            Authorization: `Bearer ${accessToken}`,
          },
        });
        if (userRes.ok) {
          userInfo = await userRes.json();
        }
      } catch {
        userInfo = {};
      }

View on GitHub (pinned to 90b52e06ff)