API · Last updated

Jev API trace identifiers

Trace identifiers for Jev integrations are your observability: OpenTelemetry traceparent, an internal X-Request-Id, or a decision UUID. The public evaluation body does not document a TypeSafe-issued trace token you can fetch later.

This page is for builders who searched an extra “endpoint” name. jev.pro is an independent unofficial field guide — not affiliated with TypeSafe AI. We do not sell or issue keys. Confirm first-party routes on docs.typesafe.ai/api.

The public API reference documents one evaluation route — POST https://api.typesafe.ai/v1/systemone — plus GET /v1/models. This title is not a separate first-party URL in that reference. Treat the capability as something you implement around the official call.

Steps

  1. Generate or propagate a request id before the POST.
  2. Log it beside response.model, usage, and the full answers map.
  3. Store the same id on handoff tickets.
  4. Do not expect /v1/traces/{id}.

Request / response shape

Official response fields: model, answers, usage. Your id lives in your headers and database.

Pitfalls

See also

FAQ

Does TypeSafe return x-typesafe-trace?

Not in the public reference we used. If you see a header, treat it as vendor-specific and confirm in docs.

Decision trace vs OTel?

OTel is transport. A decision trace is the payload you persist.

Is this a documented TypeSafe URL?

No.

What this page does not claim

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.

Sources