Skip to main content
POST
OpenAI-Compatible Chat Completions
Theo implements the OpenAI Chat Completions wire protocol at POST /api/v1/chat/completions. Any application that uses the OpenAI SDK can point baseURL at https://www.hitheo.ai/api/v1, swap in a Theo API key, and keep working — the endpoint accepts the same { model, messages, stream, temperature, ... } shape and returns the same chat.completion / chat.completion.chunk objects.
The response shape is identical to OpenAI. The routing underneath is Theo — intent classification, model selection, and automatic failover. Pass model: "theo-1-auto" to let Theo pick the best engine per request.

Base URL

Use the canonical www host. The OpenAI SDK appends /chat/completions, so this base URL resolves to the real POST /api/v1/chat/completions route:
Always use the www host. The apex https://hitheo.ai 307-redirects to www, and most HTTP clients strip the Authorization header across that redirect — the request arrives unauthenticated and returns 401.

Authentication

Uses the standard Bearer-token header. Your Theo API key replaces your OpenAI key.

Drop-in Example (OpenAI SDK)

Streaming

Set stream: true to receive an SSE stream of chat.completion.chunk objects terminated by data: [DONE], exactly as OpenAI does.

Supported model Values

Pass any Theo-branded model ID. theo-1-auto is recommended so Theo’s intent classifier picks the best engine per request; pass a specific engine if you want to pin the routing. Unknown model strings fall back to auto and Theo routes the request like any other prompt.

Request Body

The body is the standard OpenAI Chat Completion shape. Fields not listed below are accepted but ignored (e.g. top_p, n, max_tokens, user).
string
default:"theo-1-auto"
A Theo model ID. See the table above for valid values.
object[]
required
The conversation so far. Each message has { role, content }. Supported roles: system, user, assistant. tool messages are accepted but ignored (Theo owns tool-call state internally).The last user message is treated as the prompt. All system messages are merged into a single system prompt that overrides Theo’s default persona. Prior user/assistant turns are injected as conversation context.
boolean
default:"false"
When true, returns an SSE stream of chat.completion.chunk objects terminated by data: [DONE].
number
Sampling temperature (0–2).
string
Theo-specific. Attach this completion to an existing Theo conversation so its memory persists across channels. Omit to send a stateless request.
string[]
Theo-specific. Activate skills by slug for this request. Merged with the user’s installed skills.
object
Theo-specific. Arbitrary key-value data attached to the audit log.

Response

A standard OpenAI chat.completion (or chat.completion.chunk for streaming). Theo-specific metadata is returned under a theo_metadata extension so it doesn’t collide with existing OpenAI client expectations.

When to use /v1/completions instead

  • You need a single-turn prompt string instead of a message array.
  • You want the richer native Theo response (follow-ups, artifacts, tool traces) instead of the OpenAI shape.
  • You want to control persona or response_style per request.
See Create Completion for the native endpoint.

Per-key orchestration applies

This endpoint runs the same per-key orchestration as the native endpoint: whatever you configured for the API key — the Orchestrator graph, model pins, Gateway Guardrails, Routing Studio preferences, the model allowlist, and the context-window guard — governs requests here too. So a key you shaped in the dashboard or via the MCP tools behaves identically whether you call it through the OpenAI SDK or the native API. Guardrails can deny (422), a model outside the key’s allowlist is rejected (403), and an oversize request returns 400 context_length_exceeded. Keys with no such configuration are unaffected — they route on Theo’s defaults exactly as before.

Errors

Returns the same error envelope as every other v1 endpoint: