Skip to content
中文

Claude Sonnet 4.6 API documentation

Integrate Claude Sonnet 4.6 with your VezAPI key. The operations below share the same authentication and account balance.

Text-only requests require an integer max_tokens from 1 to 8,192. The JSON request limit is 64 KiB. Media, tools, thinking and prompt caching are currently unavailable.

Base URL: https://api.vezapi.com
Send Authorization: Bearer YOUR_VEZAPI_KEY. Use a unique Idempotency-Key for each submission; reuse it only when checking the same request.

Claude Sonnet 4.6

POST/claude/v1/messages

Model IDs: claude-sonnet-4-6

ParameterTypeDescription & constraints
model
required
string

Model id for this page, e.g. `claude-sonnet-4-6`. Available ids are listed by `GET [see VezAPI documentation]

Values: "claude-sonnet-4-6"

messages
required
array

Conversation messages in chronological order.

minItems: 1

messages[].role
required
string

Values: "user", "assistant"

messages[].content
required
string

Text content. Total JSON request size must not exceed 64 KiB.

stream
optional
boolean

If set to true, the response is returned as an SSE stream.

Default: true

max_tokens
required
integer

Required output token limit, 1–8192. Only text-only requests without tools, thinking or caching are enabled.

Default: 4096

minimum: 1

maximum: 8192

Request example
curl -X POST 'https://api.vezapi.com/claude/v1/messages' \
  -H 'Authorization: Bearer YOUR_VEZAPI_KEY' \
  -H 'Idempotency-Key: your-unique-request-id' \
  -H 'Content-Type: application/json' \
  -d '{
  "model": "claude-sonnet-4-6",
  "max_tokens": 256,
  "messages": [
    {
      "role": "user",
      "content": "Hello!"
    }
  ]
}'
Responses and errors

HTTP 200

Request successful.

ParameterTypeDescription & constraints
role
optional
string

Returned message role

usage
optional
object

Usage information returned in the response

usage.input_tokens
optional
integer

Input token count

usage.output_tokens
optional
integer

Output token count

usage.cache_creation_input_tokens
optional
integer

Cache creation input token count

usage.cache_read_input_tokens
optional
integer

Cache read input token count

usage.service_tier
optional
string

Service tier

stop_reason
optional
string

Reason why generation stopped

model
optional
string

Actual model version returned in the response

id
optional
string

Unique message identifier

credits_consumed
optional
number

Credits consumed by the request

type
optional
string

Top-level response object type

content
optional
array

Response content blocks

content[].input
optional
object

Tool input arguments

content[].caller
optional
object

Tool caller metadata

content[].caller.type
optional
string
content[].name
optional
string

Tool name

content[].id
optional
string

Tool call identifier

content[].type
optional
string

Content block type

HTTP 400

Bad Request - Invalid request parameters

ParameterTypeDescription & constraints
error
optional
object
error.message
optional
string
error.type
optional
string

HTTP 401

Unauthorized - Invalid or missing API key

ParameterTypeDescription & constraints
error
optional
object
error.message
optional
string
error.type
optional
string

Task status and callbacks

For asynchronous tasks, keep the returned taskId. Query GET /api/v1/jobs/recordInfo?taskId=... or provide callBackUrl when creating the task. Only the account that created a task can access it or derive new resources from it.

A timeout can mean the submission was accepted. Inspect the existing request in your dashboard; do not create another task automatically. Callback delivery is retried and may arrive more than once. Deduplicate with X-VezAPI-Event-Id.

Files, logs and billing

Generated media normally follows a 14-day provider lifetime; uploaded files expire after 24 hours. Save the files you need before expiration. VezAPI streams registered files without keeping a permanent media library. Request logs are retained for two calendar months.

Credits are reserved before submission. Final deductions match actual discounted consumption one for one. Unknown usage pauses new paid requests. If available funds cannot cover final usage while protecting other reservations, settlement stays pending until funded; model usage cannot make the wallet negative. Time-based inputs require server-side metadata reads; a failed read prevents submission.