Skip to main content
The Omnia API has two parts, both served from https://gateway.omnia-voice.com/v1 and authenticated with the same workspace API key:
  • Inference API: OpenAI-compatible endpoints for chat, embeddings, rerank, and the Responses API.
  • Management API: everything else in the improvement workflow. Capture and setup, request logs and datasets, grades (labels), judges (criteria), evals and deploy gates, fine-tuning and reinforcement learning, dedicated GPU endpoints, and model aliases and versions. (The older base https://platform.omnia-voice.com/api/v1 keeps working as an alias.)

​
Authentication

Every request uses a Bearer token:
A missing, malformed, or revoked key returns 401 with the standard error envelope. See Authentication for creating and managing keys.

​
One dialect

  • Responses are snake_case. Every response body uses snake_case keys (base_model, created_at, win_rate). Model names used as map keys pass through untouched.
  • List envelopes. The measurement products (logs, labels, criteria, evals, model versions) wrap collections as {"object": "list", "data": [...]}, and the logs list adds total, limit, and offset. The training and infrastructure products return their natural shapes: fine-tuning jobs and files and dedicated endpoints return plain arrays; GRPO returns {"runs": [...], "candidates_waiting": n, ...}.
  • Request bodies vary by product. The measurement endpoints accept snake_case bodies (judge_prompt, sample_count). The training and infrastructure endpoints (fine-tuning jobs, GRPO runs, environment tools, dedicated endpoints, model-version adoption) validate camelCase bodies (baseModel, promptCount, endpointUrl). Each endpoint’s schema in this reference states which dialect it speaks; follow the schema, not a guess.
  • Errors are nested. Refusals use the same envelope the gateway emits, so one parser handles both surfaces:
type is one of invalid_request_error, insufficient_quota, rate_limit_error, or api_error; code is the machine-stable cause (invalid_api_key, not_found, insufficient_permissions, insufficient_balance, precondition_failed, logging_disabled, …). A small number of body-validation refusals on the training and infrastructure endpoints return a flat {"error": "<message>"} string instead; treat any error field, object or string, as the refusal.

​
How the reference is organized

The endpoint groups in the sidebar are ordered the way the improvement workflow runs: capture traffic through the gateway (or OTLP ingest), read and curate logs, grade, calibrate judges, run evals and gate deploys, train, serve on dedicated capacity, and repoint aliases at what won.

Inference

Chat, embeddings, rerank, responses, models. OpenAI-compatible.

Capture & setup

OTLP trace ingest for your own instrumentation, and the setup-status probe that doubles as the cheapest possible key check.

Logs & datasets

Browse and export logged exchanges, read whole agent runs, curate training datasets with a disjoint eval holdout.

Grades & judges

Push ground-truth labels, create judges, calibrate them against your grades, scan traffic for suspects, auto-improve one consented call at a time.

Evals & gates

Queue judged comparisons or criterion runs, poll results, inspect every test case, and gate a deploy with one curl.

Fine-tuning & RL

Upload data, run SFT jobs, prove them with bake-offs, run online GRPO with validated rewards, download trained adapters.

Dedicated endpoints

Provision, scale, and meter private GPU capacity; serve fine-tuned weights.

Aliases & versions

Call a stable name, repoint it on evidence, adopt or roll back trained versions as audited repoints.

​
Keys that spend money

Endpoints that bill your wallet require a key minted by a workspace owner or admin, and return 403 otherwise: creating a dedicated endpoint, a fine-tuning job, a GRPO run, an eval run, or a dataset, and anything that judges (calibration, traffic scans, suggested judges, auto-improve, online monitoring config). Read-only endpoints work with any workspace key, except the training surfaces (GRPO, RAFT, environment tools, model versions), which are admin-read as well. Money-creating endpoints also carry a per-workspace abuse guard (default 20 requests per 60 seconds). Past it you get 429 with a Retry-After header.

​
Preconditions, not failures

Two endpoints use 412 Precondition Failed for “not proven yet”: GET /v1/evals/{id}/gate when a requested check fails (or the run isn’t DONE), and PUT /v1/aliases when the evidence policy refuses an unproven repoint. The request was well-formed and permitted; the proof isn’t there yet. Pipelines can treat 412 as “stop the deploy” without parsing anything.

​
Dashboard-only features

Some capabilities are managed in the dashboard rather than the API:
  • Billing & wallet: top-ups, auto-reload, usage export. There are no /v1 billing endpoints today.
  • Enabling request logging: the consent toggle itself is a workspace setting. Until it’s on, the logs, export, and trace endpoints return 409 with code logging_disabled rather than an empty list that would read as “no traffic”.
  • Whole-run (trace) grading and the review queue: labels created over the API are request-scoped.
  • Starting RAFT rounds: GET /v1/raft/rounds is read-only observability; rounds start from the dashboard.
  • Team & access, observability charts, playground.
These are described in the Documentation tab.