APIQIKAPIQIK
Docs
API reference

API Overview

Review Base URLs, authentication, registered endpoints, request conventions, and response handling.

APIQIK is a model gateway. Client requests pass API key authentication and model routing first, then the matching provider adapter returns a compatible-protocol response. Model names, available capabilities, and prices are deployment-side dynamic data and should not be hard-coded in clients.

Current capability surface

By capability, the current catalog provides models in three categories:

CapabilityEndpoint
Chat / textPOST /v1/chat/completions and compatible aliases (including vision and reasoning subclasses)
Image generation and editingPOST /v1/images/generations, /v1/images/edits
Video generationPOST /v1/videos and other asynchronous task entries

For the models actually available, use your billing page or GET /v1/models.

Base URL

Use the Base URL configured for the deployment and append the protocol prefix. <BASE_URL> below represents the deployment address.

ProtocolBase pathAuthentication
OpenAI-compatible<BASE_URL>/v1Authorization: Bearer <API_KEY>
Gemini-compatible<BASE_URL>/v1betax-goog-api-key, ?key=, or Bearer
Anthropic-compatible<BASE_URL>/v1x-api-key or Bearer

Use Content-Type: application/json for JSON request bodies. Image editing accepts both multipart/form-data and application/json. Bodyless queries and WebSocket handshakes do not require the header. Character encoding is UTF-8.

Main registered endpoints

CapabilityMethod and pathResponse
OpenAI/Anthropic/Gemini model listGET /v1/modelsRequires a valid API key; headers or query parameters select the protocol format, never the platform envelope
Gemini model listGET /v1beta/modelsRequires a valid API key; always returns Gemini format
Model-square catalogGET /v1/public/modelsRequires neither login nor an API key; returns the platform envelope (success + data.models)
Chat CompletionsPOST /v1/chat/completions, /v2/chat/completions, /api/v3/chat/completionsJSON or SSE
ResponsesPOST /v1/responses, /api/v3/responsesJSON or SSE
Responses WebSocketGET /v1/responsesWebSocket JSON messages
Image generationPOST /v1/images/generations, /api/v3/images/generationsJSON or image stream events
Image editingPOST /v1/images/editsJSON
Video generationPOST /v1/videos, /v1/videos/generations, /v1/video/generationsAsynchronous task JSON
Video status and contentGET /v1/videos/{video_id}, GET /v1/videos/{video_id}/contentJSON or redirect
Anthropic MessagesPOST /v1/messagesJSON or SSE
Gemini content generationPOST /v1/models/{model}:generateContent, /v1/models/{model}:streamGenerateContent, /v1beta/models/{model}:generateContent, /v1beta/models/{model}:streamGenerateContentJSON or SSE
Gemini InteractionsPOST /v1beta/interactionsJSON or streaming response
MiniMax music and lyricsPOST /v1/music_generation, /v1/lyrics_generationJSON
Generic asynchronous tasksPOST /v1/tasks, GET /v1/tasks, GET /v1/tasks/{id}, POST /v1/tasks/{id}/cancelAsynchronous task JSON
DashScope native tasksPOST /api/v1/services/aigc/{service}/{operation}, GET /api/v1/tasks/{task_id}JSON or asynchronous task JSON
Volcano Ark native video tasksPOST /api/v3/contents/generations/tasks, GET /api/v3/contents/generations/tasks/{task_id}Asynchronous task JSON

Whether some of these routes are registered depends on whether the deployment injects the corresponding task, storage, and idempotency dependencies; they cannot be called when disabled. Video routes require the provider-task publisher; generic asynchronous tasks, DashScope, and Volcano Ark tasks require their respective business dependencies.

OpenAI-compatible aliases use the corresponding protocol request body format, although native routes may adapt the response format by path. Baidu Qianfan V2 uses /v2/chat/completions. The Volcano Ark OpenAI-compatible entry points use /api/v3/chat/completions, /api/v3/responses, and /api/v3/images/generations. The three video paths use the same asynchronous submission handler.

Common request headers

HeaderRequiredDescription
AuthorizationDepends on the endpointBearer-protected endpoints use Bearer <API_KEY>. The gateway also accepts a bare sk-... credential where Bearer authentication is used.
Content-TypeDepends on the request bodyUse application/json for JSON requests; image editing accepts both formats. Query endpoints and the WebSocket handshake normally have no request body.
X-Request-IdNoA valid value is propagated. If it is missing or invalid, the gateway generates one and returns it in the response.

Protocol-specific authentication rules are:

  • OpenAI-compatible routes normally use Authorization: Bearer <API_KEY>.
  • Anthropic-compatible routes accept x-api-key or Authorization: Bearer <API_KEY>. For GET /v1/models, a non-empty anthropic-version header or the presence of an x-api-key header selects the Anthropic response format.
  • Gemini-compatible routes accept the key query parameter, x-goog-api-key, or Authorization: Bearer <API_KEY>.

GET /v1/models and GET /v1beta/models return 401 for missing or invalid API keys. The public model-square list uses /v1/public/models; credential presence does not switch routes.

Never expose API keys in browsers, mobile apps, or public repositories.

Request and response principles

  • Use model IDs from the corresponding protocol's model-list endpoint or the current console catalog.
  • Optional parameters for chat, images, and other endpoints depend on the target model; the gateway does not guarantee identical support across models.
  • Tolerate added response fields and branch on HTTP status and structured error fields rather than error-message text.
  • Parse HTTP streams as SSE events, not TCP packets, and WebSocket responses by message boundaries.
  • Retain the HTTP status, response X-Request-Id, model ID, and request time for diagnostics.

Where to call from

Send requests from a trusted backend. Keep API keys, prompts that contain sensitive data, and provider credentials out of browser code and diagnostic logs.

Unregistered endpoints

The current route table does not register OpenAI-style /v1/files or /v1/batches. Their pages describe planning boundaries, not callable endpoints.