Jev API,
from request to decision.

DOCUMENTED PROVIDER CONTRACT

What TypeSafe documents today.

Checked on September 20, 2026 against TypeSafe’s API documentation and model specifications. These are documented facts about the direct TypeSafe API, not statements about BeatAPI behavior. Check the sources before production use, because specifications change.

The model reads the state once and evaluates every question against it in parallel, so adding a second or third question about the same state is cheaper than sending the state again.

curl https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": "Help! My payouts have been failing for 3 days.",
    "questions": {
      "is_urgent": { "type": "noul", "instructions": "Does this convey urgency?" }
    }
  }'

Label: documented by the provider. The BeatAPI route will use its own endpoint, credential, and model ID, which this site will publish only after live verification.

REQUEST SHAPE

One state. Many questions.

A Jev request combines a shared state, a model identifier, and a map of questions. Question keys are controlled by your application and return under the same keys.

{
  "model": "jev-latest",
  "state": {
    "ticket": "Login fails for all new users",
    "releaseInHours": 18
  },
  "questions": {
    "queue": {
      "type": "choice",
      "instructions": "Which team should handle this?",
      "criteria": {
        "billing": "Payment and subscription issues",
        "technical": "Bugs and integration failures",
        "sales": "Pricing and account questions"
      }
    },
    "urgent": {
      "type": "noul",
      "instructions": "Does this require action today?"
    }
  }
}

Exact BeatAPI endpoint paths, authentication headers, and the production model ID are intentionally omitted until they are live-verified. Keep state to the facts the decision needs: it counts toward the 32k-token budget and the input price.

QUESTION TYPES

Three primitives, three answer shapes.

Use noul for a gate, choice for a route, and score for a rubric. If two outcomes overlap, the probability mass splits between them and your threshold becomes unreliable, so keep option descriptions distinct. For worked examples, see agent routing and guardrails.

TYPED RESPONSE

Answers your code can branch on.

{
  "model": "jev-1.13.0",
  "answers": {
    "queue": {
      "type": "choice",
      "choice": "technical",
      "probabilities": {
        "billing": 0.03,
        "technical": 0.95,
        "sales": 0.02
      },
      "confidence": 0.93
    },
    "urgent": { "type": "noul", "noul": 0.91 }
  },
  "usage": { "input_tokens": 296, "output_tokens": 20 }
}

The shape follows the documented answer fields; the numbers are illustrative. The response also reports usage, which is what you reconcile against billing. Keep the exact returned model version with your logs. If thresholds change, you need to know which model generated the historical probabilities.

INTEGRATION PATTERNS

Three production-safe patterns.

ERRORS AND RETRIES

Separate bad requests from temporary failures.

TypeSafe’s guidance is to back off exponentially on 429 and 529 instead of retrying immediately. Add jitter so many workers do not retry together, cap total attempts, and decide in advance what your system does when the decision never arrives: usually route to review or a safe stop, never to an automatic side effect. See the guardrails pattern for fail-safe defaults.

BEATAPI STATUS

The access path is reserved, not advertised as live.

Before this site enables an API button, the integration must verify authentication, request validation, typed output, model version, token usage, billing, task logs, and an end-to-end example. Until then, every access control remains visibly disabled.