different-ai/openwork · error · Error

Failed to load API keys (${response.status}).

Error message

Failed to load API keys (${response.status}).

What it means

loadApiKeys in the Den dashboard fetches GET /v1/api-keys via requestJson and, when the HTTP response is not ok, throws getRequestError(payload, response, 'Failed to load API keys (<status>)'). The generic message is enriched with any error detail the server returned in the payload. It surfaces auth/session problems and server faults from the Den control plane.

Source

Thrown at ee/apps/den-web/app/(den)/dashboard/_components/api-keys-screen.tsx:97

        if (!orgId || !access.canViewSettings) {
            if (isCurrent()) {
                setApiKeys([]);
            }
            return;
        }

        if (isCurrent()) {
            setBusy(true);
            setError(null);
        }
        try {
            const { response, payload } = await requestJson(
                `/v1/api-keys`,
                { method: "GET" },
                12000,
            );
            if (!response.ok) {
                throw getRequestError(payload, response, `Failed to load API keys (${response.status}).`);
            }

            if (isCurrent()) {
                setApiKeys(parseOrgApiKeysPayload(payload));
            }
        } catch (nextError) {
            if (isReauthRequiredError(nextError)) {
                throw nextError;
            }

            if (isCurrent()) {
                setError(
                    nextError instanceof Error
                        ? nextError.message
                        : "Failed to load API keys.",
                );
            }
        } finally {

View on GitHub (pinned to 2b7df46e8a)

Solutions

  1. Read response.status and the server payload detail to identify the exact cause (401/403 vs 5xx).
  2. For 401/403, re-authenticate the Den session (sign in again) and retry.
  3. Verify the Den API base URL / deployment routing is correct for the current org.
  4. For 5xx/429, retry with backoff; check Den server health/logs if it persists.

Example fix

// before
try { await loadApiKeys(); } catch (e) { setError(String(e)); }
// after
try {
  await loadApiKeys();
} catch (e) {
  if (e.status === 401 || e.status === 403) { redirectToSignIn(); return; }
  setError(`Could not load API keys (${e.status ?? "network"}). Retry or contact your Den admin.`);
}
Defensive patterns

Strategy: try-catch

Validate before calling

if (!session?.token) throw new Error("Sign in to Den before loading API keys");

Type guard

function hasActiveSession(s) {
  return Boolean(s && typeof s.token === "string" && s.token.length > 0 && (!s.expiresAt || Date.now() < s.expiresAt));
}

Try / catch

try {
  await loadApiKeys();
} catch (e) {
  const status = e.status ?? Number(/\((\d{3})\)/.exec(e.message)?.[1]);
  if (status === 401 || status === 403) redirectToSignIn();
  else if (status >= 500 || status === 429) scheduleRetryLoad();
  else setError(e.message);
}

Prevention

When it happens

Trigger: GET /v1/api-keys returns any non-ok status: 401/403 (expired or missing Den session, wrong org), 404 (wrong base URL/gateway), 5xx (Den server error), or 429 (rate limited); the request itself has a 12s timeout handled separately.

Common situations: Session token expired after idle; user switched orgs without refreshing the session; API base URL misconfigured in the Den web deployment; Den backend outage; load balancer returning 502/503.

Understand the failure class

Background: 'Something went wrong' / 'Request failed (500)' / 'HTTP error! status: 404' — what failed HTTP requests actually mean and how to find the real cause — this error's family across 28 libraries.

Related errors


AI-assisted analysis of different-ai/openwork@2b7df46e8a (2026-09-01). Data as JSON: /api/errors/5c3060c0202f49c4. Report an issue: GitHub.