Chat Completions API

Base URL and authentication

Base URL: https://orchestrator.tenvor.io/v1
Models:   GET /v1/models
Chat:     POST /v1/chat/completions

Configure an OpenAI-compatible SDK with the base URL, not the full chat path. JetBrains endpoint fields may append a different suffix; use the version-dependent JetBrains guide.

Programmatic calls use Authorization: Bearer <your API key> and JSON requests use Content-Type: application/json. Obtain a key explicitly from Console, keep it in your client's supported secret storage, and never place it in a URL, repository, screenshot or log. Playground uses a managed session instead.

Make a small text request

Replace the model placeholder with an ID returned by authenticated GET /v1/models. Check the current catalog before sending; the 64-token output budget below is an example and must fit the selected model's current limit.

{
  "model": "REPLACE_WITH_CURRENT_MODEL_ID",
  "messages": [
    {
      "role": "user",
      "content": "Reply with one short sentence about a blue square."
    }
  ],
  "max_completion_tokens": 64,
  "temperature": 0
}

• messages accepts ordered system, user and assistant text messages. Tool history additionally uses assistant tool_calls and matching tool result messages.
• Use max_completion_tokens or the deprecated max_tokens; do not send both. Set a small explicit budget for your first request.
• temperature, top_p and stop are supported within the published bounds. One choice is returned; omit the unsupported n field.
• response_format, multiple choices, unknown properties and unsupported combinations are rejected. This interface does not execute tools on the server.

For a runnable request using your current selection, open Playground, compose and estimate the same body, and use its server-side snippets with your supported credential storage. Do not paste a key into the visible example.

Incremental text and terminal success

Set stream: true for standards-framed chat.completion.chunk SSE. After admission, an assistant-role event and bounded keepalives may precede content. They are not visible model output or proof of a completed request.

The V10 dynamic route can present incremental text from signed, durably accepted batches. Updates may arrive in bursts, and other paths may buffer a result. There is no promise of one update per token, immediate first content or uniform spacing.

Accumulate delta.content in order. Treat a successful terminal outcome as separate from partial text. A stream error, abrupt close or [DONE] marker alone does not prove success; [DONE] only marks the end of SSE events. Do not synthesize a finish reason on interruption.

With stream_options: {"include_usage": true}, the standard usage chunk is emitted on successful completion. The authenticated durable result and receipt remain the authority for billing and result recovery.

Complete tool calls before execution

Bounded function tools are supported on Standard. Your client executes each approved function. Accumulate indexed tool-call arguments, wait for the complete validated call and a successful terminal outcome, then apply your client's approval policy. Never execute partial arguments.

Return each result as a tool message with its matching tool_call_id after the corresponding assistant call. Resolve all outstanding calls before the next continuation. Function definitions, arguments, identifiers, schema depth and total history have bounds.

tool_choice accepts none, auto, required or a named function when tools are present. parallel_tool_calls: false permits at most one returned call. With absent or empty tools, omit these controls or use tool_choice: "none" and parallel_tool_calls: false; parallel tool calling requires a non-empty tool list.

Assurance and capability boundaries

Assurance is immutable server deployment policy for the request, not a client-selected upgrade. The response's validation_tier reports the actual tier. Public prices for a tier do not establish that its capacity or feature combination is available.

Tool calling is Standard-only in the current alpha; Audited and Verified do not support tool requests. Fast service is not a live commercial option documented by this guide. Eligible opt-in sessions may retain a private prefix for a later request; ordinary requests remain cold across requests.

Recover accepted work without blind retries

Retain the returned x-request-id privately. Accepted work may return HTTP 202 with an authenticated result_url. Use the account-scoped GET /v1/results/{x-request-id} result lookup and inspect the durable outcome and receipt.

The optional Idempotency-Key binds one logical request to its normalized terms. Use the same key for an exact retry; changing terms with that key is a conflict. Without it, another POST is a new billable request. Disable automatic retries until your client handles ambiguous outcomes and reconciliation.

A disconnect, HTTP 503 or HTTP 504 alone does not establish whether work was admitted or whether a charge is due. Keep the request reference privately, check the authenticated result and account activity, and reconcile accepted work before retrying. Do not turn a partial answer into a successful completion.

Reservations and receipts · Troubleshooting