Jev errors and retries
Jev errors and retries are the official HTTP failure classes and the backoff TypeSafe tells you to use on POST /v1/systemone and GET /v1/models. Documented statuses: 401, 422, 429, and 529. We do not document unofficial codes. Official Python (typesafe-sdk) and JavaScript (@typesafe-ai/sdk) clients retry 429/529 under their default policy.
This page is for builders wiring TypeSafe Jev (System One) into agents, routing, or evals. jev.pro is an independent unofficial field guide — not affiliated with TypeSafe AI. We do not sell or issue keys. Confirm the error table on docs.typesafe.ai/api.
| Status | Meaning | Retry? |
|---|---|---|
401 Unauthorized |
Missing or invalid API key | No — fix the key |
422 Unprocessable Entity |
Validation failed; body names the field | No — fix the body |
429 Too Many Requests |
Token/second or request/minute limit | Yes — exponential backoff |
529 Overloaded |
TypeSafe temporarily overloaded | Yes — exponential backoff |
Official SDKs honor retry-after. Raw HTTP must do the same. Do not tight-loop. TypeSafe’s public 1200 RPM figure is a vendor claim; your account may differ. Confirm on the models / limits pages.
Application-level “errors” (low confidence, policy block, missing context) often arrive as 200 with a distribution you refuse to act on. Those are not HTTP statuses — see the error cluster. Schema-safe ≠ factually correct.
Channel callouts (not extra first-party codes)
If you see 402 insufficient credits, that is typical of an OpenRouter-style wallet — TypeSafe’s public table does not list 402. Marketplace 403 / customer verification is a Vercel or worker binding problem. Log which host you called. A 401 on Gateway is not a 401 on api.typesafe.ai.
Testing failures without inventing a route
Contract-test 401/422 in Jev API testing against your wrapper mocks if you lack a shared sandbox key. There is no documented /v1/test. Never commit live secrets. This site will not accept a key or proxy a failing call.
Production notes
- Retries of 429/529 may repeat an evaluation. That is usually cheap (vendor claim: output free; input metered). Repeating a transfer is not — implement uniqueness in your database, not a header we have not seen documented.
- Do not retry 422 after a deploy unless you changed the body.
- Capture the JSON body and a request id if the door sends one. Ask TypeSafe — not this site — what an undocumented status means.
- Pin
jev-1.13.0so a moving alias is not mistaken for “the API started erroring.”
See also
- API hub — where HTTP contract pages live
- Rate limits — vendor RPM / token-per-second claims
- API keys — dashboard secrets; we do not issue them
- Retry semantics pattern — application backoff notes
FAQ
What if I see another status?
Capture the JSON body and ask TypeSafe — not this site — what it means.
Does retry duplicate a side effect?
The evaluation is (as documented) a judgment. Your downstream tool call is what must be idempotent — idempotency pattern.
401 after a gateway swap?
You probably sent a TypeSafe key to a Gateway URL or the reverse.
Should CI retry flaky 422s?
No. 422 means the fixture is wrong. Pin the body and the model id.
What this page does not claim
- Official TypeSafe status, logos, or support.
- That jev.pro sells, issues, or proxies API keys.
- Extra first-party HTTP routes beyond
POST /v1/systemoneandGET /v1/modelsunless the API reference lists them. - Invented latency SLOs, search volume, or unofficial prices.
- That a schema-constrained answer is automatically factually correct.
Disclaimer
This is an independent unofficial site and is not affiliated with TypeSafe AI; official documentation is available at https://docs.typesafe.ai. Never treat jev.pro as TypeSafe official documentation. We do not sell, issue, or proxy API keys.