JevModel API: request and response

Create a JevModel API key in account settings after verifying your email. Keep it on your server and POST to this site’s /api/v1/systemone endpoint. This example asks one yes/no question. The model is fixed to typesafe/jev-1.13 through OpenRouter; do not send a model field.

curl -X POST https://jevmodel.app/api/v1/systemone \
  -H "Authorization: Bearer $JEVMODEL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"state":"The customer was charged twice and requests a refund.","questions":{"escalate":{"type":"noul","instructions":"Should a human billing specialist review this request now?","criteria":{"true":"A specialist should review it now.","false":"No immediate review is needed."}}}}'

Send a text state, JSON object, or nonempty JSON array plus 1–8 named questions. The serialized state and the validated full request must each fit within 8,000 characters. Question IDs start with a lowercase letter and contain up to 40 lowercase letters, digits, or underscores. Instructions need 8–600 characters. Choice needs 2–12 named options; Score needs 2–10 ordered levels; Noul needs both true and false descriptions. Each description needs 2–350 characters.

Successful calls use the JevModel envelope below. The data object contains a request_id, answers keyed by question ID, upstream usage, and the remaining quota. The example values are illustrative. Choice may include a selected label and probabilities; Score is numeric and may be fractional; Noul is the probability of true from 0 to 1. Your application must choose its own action thresholds.

{
  "code": 0,
  "message": "ok",
  "data": {
    "request_id": "example-id",
    "answers": {
      "escalate": {
        "type": "noul",
        "noul": 0.94
      }
    },
    "usage": {
      "inputTokens": 186
    },
    "quota": {
      "used": 1,
      "limit": 5,
      "tokenBalance": 100000,
      "globalUsed": 1,
      "globalLimit": 1000,
      "dayUtc": "2026-09-28"
    }
  }
}

Errors use {"code":-1,"message":"ERROR_NAME"}. HTTP 400 means invalid JSON or request fields; 401 an invalid key; 403 unverified email; 413 an oversized request; 429 insufficient daily capacity or token balance; 502 an unusable upstream result; and 503 an unavailable model connection. Check both HTTP status and code. Five successful runs are free each UTC day, subject to site capacity; later successful runs deduct the model-reported input tokens from the shared Playground/API balance. Failed runs are refunded. This API does not support idempotency keys: if a response is lost after a successful run, check account history and balance before retrying to avoid a second charge.