API documentation

OpenAI-compatible chat completions. Technical description of how the service behaves; it is not a service-level commitment.

Quick start

Base address https://api.privatedeskai.com/v1. Get a key on the account page and send it as a bearer token.

curl https://api.privatedeskai.com/v1/chat/completions \
  -H "Authorization: Bearer YOUR_KEY" -H "Content-Type: application/json" \
  -d '{"model":"deepseek-ai/DeepSeek-V4-Flash-0731","messages":[{"role":"user","content":"Hello"}]}'

Streaming (server-sent events) - add "stream": true and read lines starting with data: until data: [DONE]:

curl -N https://api.privatedeskai.com/v1/chat/completions \
  -H "Authorization: Bearer YOUR_KEY" -H "Content-Type: application/json" \
  -d '{"model":"deepseek-ai/DeepSeek-V4-Flash-0731","stream":true,"stream_options":{"include_usage":true},"messages":[{"role":"user","content":"Hello"}]}'

With the OpenAI SDKs set base_url to the address above and use your key.

Models

GET /v1/models lists them: deepseek-ai/DeepSeek-V4-Flash-0731 and the fast-mode alias deepseek-v4-flash-fast. Context window 400,000 tokens, output up to 16,000 tokens (see /models).

Limits

Technical limits, not promises: a limit on request rate per address, a limit on concurrent streams per key, a limit on request body size. Exceeding the rate or stream limit returns 429 with a Retry-After header; a body that is too large returns 413.

Errors

Errors use the OpenAI format {"error":{"message","type","code","param"}}; every response carries X-Request-ID.

Status	When	Error code (examples)
400	the request cannot be answered: invalid JSON, wrong type, a value out of range (temperature, top_p, max_tokens), a missing field, `n` above 1	`invalid_json`, `invalid_type`, `invalid_value`, `missing_required_parameter`
401	the key is wrong; the response carries `WWW-Authenticate`	`invalid_api_key`
402	no key and the request asks for payment by the x402 protocol (agents that pay per request)	x402 payment requirements
404	unknown model	`model_not_found`
413	request body too large	`request_too_large`
429	rate or concurrent-stream limit; wait for `Retry-After`	`rate_limit_exceeded`
502, 503	no provider could answer (all failed or the answer was unusable); `X-Request-ID` identifies the request, `Retry-After` may be present	`upstream_error`, `all_providers_unavailable`

What a stream does when something goes wrong

If a provider stops sending data for about eight to ten seconds or closes the stream early, the gateway tries to continue the answer on another provider; the client sees one continuous stream.
If it cannot continue, the stream ends with an event data: {"error":{...,"code":"stream_interrupted"}} followed by exactly one data: [DONE]. A stream never just goes silent.
If you close the connection, generation is stopped at once.

Billing, in plain words

You pay for the tokens that were delivered to you; what was not delivered is not billed.
Text that a Gonka-network provider appended to a very short answer (see the note on benchmarks) is part of the delivered answer and is billed like any other delivered text.
A non-streaming answer is billed only after it has been delivered completely; if it could not be delivered, it costs nothing.
If you cancel a stream, you are billed for the part that was delivered, and generation stops.
A stream that ended with an error event is not billed.
A normal stream is billed for the tokens it delivered.

Tariffs

Standard: requests go to Gonka network providers in priority order; behind them stands an insurance provider outside the Gonka network. Super Deal - economical tariff, depends on the Gonka network, no insurance outside Gonka: Gonka providers only.

Prices are on the pricing page.

Parameter support is described on the compatibility page; measured results are on benchmarks.