Jev API 401: Cannot Authenticate With the Server
Last checked · Independent guide, not affiliated with TypeSafe AI
A 401 from the Jev API means TypeSafe received an API key but did not accept it: it is mistyped, revoked, from another service, or sent with the wrong prefix. Copy a fresh key from the TypeSafe console, send it as 'Authorization: Bearer <key>', and make sure your code is not picking up an old environment variable.
The exact error
Section titled “The exact error”This is what TypeSafe’s API returned when we sent a made-up key on September 19, 2026:
{ "detail": { "error_type": "authentication_error", "message": "Cannot authenticate with the server. Please check your API key and try again." }}In the Python SDK it surfaces as TypeSafeAuthenticationError with the message POST https://api.typesafe.ai/v1/systemone: 401 Cannot authenticate with the server.... In the JavaScript SDK it is an AuthenticationError with status 401.
What causes it
Section titled “What causes it”In rough order of how often we would expect each:
- A copy-paste problem. A missing character, a trailing space or newline, or quotes included in the value.
- A key from another service. An OpenRouter or Vercel AI Gateway key does not work on
api.typesafe.ai; each platform issues its own keys. - A stale environment variable. Your shell,
.envfile or deployment platform still holds an old or revoked key. The SDKs readTYPESAFE_API_KEYunless you pass a key explicitly. - A revoked or deleted key in the TypeSafe console.
- The wrong header format, for example sending the key without the
Bearerprefix.
How to fix it
Section titled “How to fix it”- Create or copy a key from the API keys page of the TypeSafe console.
- Set it without quotes or spaces:
export TYPESAFE_API_KEY="paste-the-key-here"echo -n "$TYPESAFE_API_KEY" | wc -c # length check: no stray newline or spaces- Test it with the smallest possible request:
curl -s -o /dev/null -w "%{http_code}\n" https://api.typesafe.ai/v1/models \ -H "Authorization: Bearer $TYPESAFE_API_KEY"A 200 means the key works; a 401 means the key itself is the problem.
- In a deployed app, check which value the running process actually sees. Serverless platforms often need a redeploy after you change an environment variable.
401 versus 403
Section titled “401 versus 403”TypeSafe uses two different codes for key problems:
| Code | Message | Meaning |
|---|---|---|
| 401 | “Cannot authenticate with the server…” | A key was sent, but it is not valid |
| 403 | “Must supply an API key!…” | No key was sent at all |
If you see 403, the header is missing entirely; see 403: Must supply an API key.
Should you retry a 401?
Section titled “Should you retry a 401?”No. Retrying with the same key will fail the same way, and the official SDKs do not retry 401s. Fix the key and send the request again. If a key that worked earlier suddenly returns 401, check whether someone on your team rotated or deleted it in the console before assuming an outage; for real outages see Is Jev down?
On other channels
Section titled “On other channels”OpenRouter, Vercel and Cloudflare use their own keys and their own error formats. On OpenRouter, a missing header returned 401 “No cookie auth credentials found” in our test. See Jev channels compared.