Send a call to Jev as it is
POST/v1/systemone
Forwards a System One call to Jev through the proxium loop: authentication, the guardrails, the budget, routing and cost. The body and the answer are Jev's own, so a System One client changes only its base URL and its key. Proxium runs no action after the answer. A repeated call is answered from the project's exact cache. The request and the answer of each call are kept by default; a project turns that off in its settings. The feature is granted by plan, as /v1/classify is.
Request
Responses
- 200
- 400
- 401
- 402
- 403
- 429
- 503
Jev's own answer, unchanged. A call answered from the cache carries the header x-proxium-cache: exact.
bad_request for a body with no state or no questions, no_route for a route that does not start with a Jev model, and upstream_refused with Jev's status when Jev refused the call.
The bearer virtual key is missing (missing_key), or it is not valid or it is revoked (invalid_key).
The project may not send calls (subscription_required). proxium.tech is in open beta and does not return this answer.
The route starts with the platform Jev and the project has no classify grant (jev_not_granted), or a content rule of the project blocked the call (guardrail_blocked).
The key or the source used its budget window (tenant_capped or source_capped, retry-after: 60), or the project reached a monthly cap (credits_exhausted, retry-after: 3600). No project on proxium.tech has a monthly cap during the open beta.
Response Headers
Seconds to wait before the next call.
Each attempt of the failover chain failed (upstream_failed). The message gives the reason of the last attempt, or client deadline exceeded when x-proxium-timeout-ms ran out. Or: The key store or the limits store is not available (keystore_unavailable, limits_unavailable). A deployment that refuses calls while its budget store is down answers budget_unavailable with retry-after: 5; proxium.tech lets the call through.
Response Headers
Seconds to wait before the next call.