Skip to main content
POST
Native OpenAI Format (ChatCompletions)

Introduction

Universal text chat API supporting OpenAI-compatible large language models for generating conversational responses. Through a unified API interface, you can call multiple mainstream large models including OpenAI, Claude, DeepSeek, Grok, and Tongyi Qianwen.

Authentication

string
required
Bearer Token, e.g. Bearer sk-xxxxxxxxxx

Request Parameters

string
required
Model identifier, supported models include:
  • OpenAI series: gpt-5.5, gpt-5.4, gpt-5.4-pro, gpt-5.4-mini, gpt-5.4-nano, gpt-4o, etc.
  • Claude series: claude-opus-4-8, claude-opus-4-7, claude-opus-4-6, claude-sonnet-4-5-20250929, claude-haiku-4-5-20251001, etc.
  • DeepSeek series: deepseek-v4-pro, deepseek-v4-flash, deepseek-v3-1-250821, deepseek-v3, deepseek-r1, etc.
  • Grok series: grok-4, grok-4-fast-reasoning, grok-3, etc.
  • Gemini series: gemini-3.1-pro-preview, gemini-3-pro-preview, gemini-3-flash-preview, nano-banana-pro and -thinking/-nothinking / -thinking-<budget> / -thinking-low/-thinking-high variants
  • Domestic models: glm-5, glm-4.7, doubao-seed-1-8-251228 (Doubao Seed series), qwen3-coder-plus, kimi-k2.5, etc.
array
required
Conversation message list, each element contains role (user/system/assistant) and content
number
default:"0.7"
Randomness control, 0-2, higher values = more random responses
boolean
default:"false"
Whether to enable streaming output, returns SSE format chunked data
number
Maximum number of tokens to generate, controls response length
number
Nucleus sampling parameter, 0-1, controls generation diversity

Basic Examples

Advanced Features

Tool Calling (Functions / Tools)

Supports OpenAI-compatible tool calling format, applicable to GPT, Claude, DeepSeek, Grok, Tongyi Qianwen, and other models.

Structured Output (JSON Schema)

Supports controlling output format through response_format parameter, applicable to GPT, Claude, Grok, and other models.
For strict structured output, it is recommended to lower the temperature value (e.g., 0.1-0.3) and set an appropriate max_tokens to improve consistency.

Thinking Capability

Some models support thinking capability (Thinking/Reasoning), which can display the reasoning process when generating responses. Different models implement this differently:
DeepSeek models support enabling thinking capability through the thinking field:
  • Default thinking.type is "disabled", need to explicitly set to "enabled" to enable
  • The output form of thinking capability may vary by model version
  • It is recommended to use with stream: true for better interactive experience

Tongyi Qianwen Extended Features

Tongyi Qianwen models support extended features such as search, speech recognition, etc. All extended parameters need to be placed in the parameters object.
All extended parameters for Tongyi Qianwen (such as enable_search, search_options, asr_options, temperature, top_p, etc.) need to be placed in the parameters object, not at the top level of the request body.

Web Search Features

Some models support real-time web search, allowing access to the latest information and including citation sources in responses.
Claude models do not support enabling web search functionality through the web_search_options parameter, so it can only be implemented through tool calls, and may be unstable due to network and prompt reasons. For details, see Tool Calling (Functions / Tools) above.Basic Example (showing tool call flow):
Example with Location Information (showing tool call flow):
  • Search functionality will increase response time and token consumption (including search result content)
  • Search results will automatically include citation sources in the response
  • Supported models include Claude Sonnet 4, Claude 3 Opus, etc.
  • In multi-turn conversations, tool calls and results will be visible in message history, and the model can continue the conversation based on previous search results
Stability Notice:
  • Web search functionality depends on upstream proxy services and external search services, and may have the following instabilities:
    • Network fluctuations: Network connection issues may cause search requests to timeout or fail
    • Service limitations: Search services may have rate limits, timeout limits, or temporary unavailability
    • Search result quality: Some queries may not find relevant information, or search results may be of poor quality
    • Model judgment: The model will automatically determine whether a search is needed based on the question, and in some cases may not trigger a search
  • This is an inherent characteristic of web search functionality. It is recommended to:
    • Implement retry mechanisms in critical scenarios
    • Handle search failures with graceful degradation (e.g., using the model’s knowledge base to answer)
    • Avoid relying entirely on web search in scenarios with extremely high real-time requirements

GPT File Input (Responses API)

GPT-5 and other models support file input functionality, which needs to be called through the /v1/responses endpoint, not /v1/chat/completions.
You can upload PDF files by linking external URLs:
  • File size limit: Single file not exceeding 50 MB, total size of all files in a single request not exceeding 50 MB
  • Supported models: gpt-4o, gpt-4o-mini, gpt-5-chat, and other models that support text and image input

Grok Reasoning Capability

Grok models (especially grok-4-fast-reasoning) support reasoning capability. When enabled, usage.completion_tokens_details.reasoning_tokens shows the token count consumed by the reasoning process. See usage field reference below for details.

usage field reference

When calling /v1/chat/completions, the usage object in the response contains token usage statistics. This section first covers common fields (typical chat model scenarios), then scenario-specific fields that only appear with non-zero values in certain cases.

Common fields

Applies to: GPT series, Claude chat/thinking models, Gemini, DeepSeek, and other text chat scenarios via /v1/chat/completions. Does not include fields that only appear when the gateway internally calls Claude Messages protocol or image generation models — see Scenario-specific fields.
  • prompt_tokens_details and completion_tokens_details are always present in the response, even when all sub-fields are 0; 0 does not mean “unsupported”, only “not used in this request”.
  • completion_tokens_details.image_tokens (and prompt_tokens_details.image_tokens) are listed here because the structure is always present, but non-zero values only occur in special scenarios (Claude / image generation models). See Scenario-specific fields.
  • reasoning_tokens is a cross-model concept: whether the upstream is an OpenAI reasoning model, Claude extended thinking, or Gemini thinking, if “thinking” was enabled for that call, it appears in this single field.

Scenario-specific fields

The following fields only have non-zero values in specific cases: the request goes through /v1/chat/completions, but the gateway internally converts it to another protocol to call upstream (Claude Messages protocol / image generation models). The converted usage then includes these “native protocol-specific” fields.

Scenario 1: Underlying Claude call (/v1/chat/completions/v1/messages)

When you request a Claude model in OpenAI format, the gateway converts the request to Anthropic Messages protocol, then maps Claude’s usage back to OpenAI format. Claude’s cache mechanism is finer-grained than OpenAI’s (5-minute / 1-hour TTL tiers), carried by these dedicated fields:
prompt_tokens_details.cached_tokens and completion_tokens_details.reasoning_tokens also have values when calling Claude models (mapping to Claude cache-read tokens and extended-thinking tokens respectively), but these are cross-model common fields already covered in Common fields.

Scenario 2: Underlying image generation model (/v1/chat/completions/v1/images/generations semantics)

Some image generation models (e.g. Gemini native image output, gpt-image series) normally use the official /v1/images/generations usage structure (input_tokens/output_tokens + modality breakdown). When users call these models via /v1/chat/completions for conversational image generation, the gateway maps that information into chat-format usage:

Scenario 3: Channel protocol differences

These two fields are not “converted” — they are passed through as-is from specific channel upstream responses. You are unlikely to encounter them with mainstream models:

Response Format

For full usage field reference, see usage field reference above.

Error Handling

Supported Model Series

OpenAI Series

  • GPT-5.5, GPT-5.4 family (5.4 / Pro / Mini / Nano), GPT-4o, GPT-4o Mini

Claude Series (Anthropic)

  • Claude Sonnet 4, Claude 3 Opus, Claude 3 Haiku

DeepSeek Series

  • DeepSeek V3, DeepSeek R1

Grok Series (xAI)

  • Grok-4, Grok-3, Grok-3-fast, Grok-4-fast-reasoning

Tongyi Qianwen Series (Qwen)

  • Qwen3-omni-flash, etc.

Doubao Seed Series

  • doubao-seed-1-8-251228, etc.

Other Models

  • Gemini series, GLM series (including glm-5), Kimi series, etc.
For the complete model list, please see the Model Information Page.

Notes

  • In the messages list, system role is used to set model behavior, user role is for user questions
  • Multi-turn conversations require appending history (including assistant role responses)
  • Requires openai library: pip install openai
  • Different models may have different levels of support for certain features, it is recommended to check the specific model documentation before use
  • Using streaming output can improve first token response time and interactive experience
  • Tool calling requires proper timeout and retry mechanisms to avoid blocking model responses
  • Tongyi Qianwen extended parameters must be placed in the parameters object

FAQ

View FAQ for chat interface

Model List

View all supported model information