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
- Read response.status and the server payload detail to identify the exact cause (401/403 vs 5xx).
- For 401/403, re-authenticate the Den session (sign in again) and retry.
- Verify the Den API base URL / deployment routing is correct for the current org.
- 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
- Check session validity (token present, not expired) before dashboard data loads.
- Handle 401/403 with a redirect to sign-in rather than a generic error toast.
- Retry 5xx/429 with backoff; alert on sustained Den server failures.
- Verify the Den API base URL in deployment config on 404s.
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
- Failed to create API key (${response.status}).
- Failed to delete API key (${response.status}).
- request_failed
- invalid_payload
- getInstallConfigErrorMessage(payload, response.status)
AI-assisted analysis of different-ai/openwork@2b7df46e8a (2026-09-01).
Data as JSON: /api/errors/5c3060c0202f49c4.
Report an issue: GitHub.