Skip to main content
Every answer here is short on purpose and links to the page that carries the detail. Where the honest answer is “not yet” or “we do not publish that”, it says so rather than being left out.

​
Getting started

Two settings: the base URL and the key. Then one edit that is not optional, which is putting a provider in front of every model id. See Migrate from OpenAI.
A bare id such as gpt-4o-mini is not a Uniblock model id. Ids name the provider that serves them, so it is openai/gpt-4o-mini. A bare id is refused with 400 and the code model_id_not_pinned rather than being routed to whichever provider we happen to carry it under. See Models.
Ask GET /v1/models, or browse the Models screen in the dashboard. This site publishes no model list, because any list written here would be wrong the first time the catalog changed.
POST /v1/chat/completions, GET /v1/models and GET /v1/models/{id}. Those are the operations this site documents and the API reference publishes. A path this site does not document is one we make no promise about, in either direction. See OpenAI compatibility.
The instructions on this site set only the base URL and the key, which is the whole intended change. We have not published a proof run of an unmodified SDK against the production hostname, so we describe that as instructions rather than as a certification.

​
Features

Yes, as OpenAI defines it. tools, tool_choice and the tool_calls that come back all travel unchanged, streamed and not. Nothing is executed on our side. See Tool calling.
Yes, both forms, forwarded as written. Nothing here validates your schema or the reply against it. See Structured outputs.
Yes, in OpenAI’s message-part shape, to a model that takes one. See Image inputs.
Every catalog entry carries five capability words, each answering yes, no or unknown. Read unknown as “nobody has established this” rather than as “no”. See Model capabilities.
Provider prompt caching passes through unchanged, and the cached-token counts come back separately and are priced as their own kind. There is nothing of ours to enable. See Prompt caching.
Yes, with a routing profile: your own ordered list of provider/model lines, requested as profile/{identifier} in the model field. See Routing profiles.
That is what a model id is. The part before the first slash names the provider, and we never substitute a different one behind your back. A model carried by two providers is two ids with two prices.
Nothing is documented here for one. Embeddings stay off this site until the tracker says they serve real responses, and until then we would rather say nothing than describe a call you cannot rely on.

​
Money

No. A request deducts the provider’s rate at face value. The platform fee is added when you buy credit, not when you spend it. See Credits and billing.
Your account cannot pay for it. Either the balance is empty, or a ceiling somebody set has been reached. The code says which. Nothing is charged for the refusal. See Errors.
rate_limit_exceeded is your key’s request rate, and it carries Retry-After. spend_rate_exceeded is your account spend rate cap, and the lever for it is sending max_tokens. See Rate limits and spend controls.
Credit is held against a ceiling while a request runs. With no max_tokens the ceiling is the model’s published maximum output, so the request occupies more of your spend rate cap while it is in flight. The hold comes back in full at settlement either way. See Request parameters.
On the Activity screen, one row per request. The usage record is the authority on what a request cost, not a rate in the catalog. See View activity.
Yes, for a provider we already serve. Your key then answers every request to that provider and the provider bills you directly. It does not add models to your catalog. See Bring your own key.

​
Data and operations

No. What is recorded is metadata about a request: what was called, what it cost, how long it took, what happened. Never the content. See Data and privacy.
No. We keep only a hash of it, so it cannot be shown again or recovered. Replace it. See Authentication.
They are not forwarded, because they describe a pool we hold rather than a limit that applies to you. Your own limits arrive as 429 codes you can branch on. See Headers.
The request id. It is on every response on x-uniblock-request-id and on x-request-id, and inside every error body as request_id. Quote it rather than describing the symptom.
No. No figure for availability, for throughput, or for the latency the hop adds has been measured here in a way we are willing to publish, so this site claims none.
There is no version to pin beyond the /v1 in the path. The surface grows by addition, and the error envelope is the stable contract. See API reference.