Structured outputs
response_format constrains what the model writes: valid JSON, or JSON matching a schema you
provide. Both shapes follow the OpenAI convention and are forwarded to the serving endpoint.
JSON mode
{ "response_format": { "type": "json_object" } }
The model must emit a single valid JSON object. As with OpenAI, tell the model what JSON you want in the prompt — JSON mode guarantees well-formedness, not shape.
JSON Schema
json_schema pins the shape itself:
{
"model": "deepseek/deepseek-v4-flash-0731-abliterated",
"messages": [
{ "role": "user", "content": "Extract the order from: two espressos and a croissant, table 5." }
],
"response_format": {
"type": "json_schema",
"json_schema": {
"name": "order",
"strict": true,
"schema": {
"type": "object",
"properties": {
"table": { "type": "integer" },
"items": {
"type": "array",
"items": {
"type": "object",
"properties": {
"product": { "type": "string" },
"quantity": { "type": "integer" }
},
"required": ["product", "quantity"],
"additionalProperties": false
}
}
},
"required": ["table", "items"],
"additionalProperties": false
}
}
}
}
The assistant message's content is then a JSON string matching the schema:
{
"choices": [
{
"index": 0,
"message": {
"role": "assistant",
"content": "{\"table\":5,\"items\":[{\"product\":\"espresso\",\"quantity\":2},{\"product\":\"croissant\",\"quantity\":1}]}"
},
"finish_reason": "stop"
}
]
}
| Field | Type | Meaning |
|---|---|---|
json_schema.name | string | Required. A label for the schema. |
json_schema.schema | object | The JSON Schema the output must satisfy. |
json_schema.strict | boolean | Ask the endpoint to enforce the schema during generation. |
Routing
Support varies by endpoint. An endpoint that honours response_format declares it in its
supported_parameters; some additionally declare structured_outputs to signal schema
enforcement.
A request setting structured_outputs: true is only ever routed to an endpoint that declares
it, with no preference needed — an endpoint that ignores a schema hands you prose where you
needed JSON, which is the wrong kind of answer rather than a worse one. response_format alone is
also requires an endpoint declaration. The name means different things on different surfaces (JSON
mode on chat, the transcript encoding on a transcription). When the shape matters, request
structured_outputs so the endpoint's schema compliance check applies:
{
"response_format": { "type": "json_schema", "json_schema": { "name": "order", "schema": {} } },
"structured_outputs": true
}
structured_outputs: true in the request body is a capability marker: it does not change what the
model generates, it decides where the request may go. Even with strict schemas, parse and
validate the output before acting on it — the schema constrains generation, it does not replace
validation at your boundary.
The declaration is checked rather than taken. Every endpoint declaring structured_outputs is sent
a small schema every six hours, and the check passes only if the reply parses against it — an
engine that accepts response_format and answers in prose fails, because that is the failure the
declaration exists to rule out. An endpoint whose latest check failed has the promise withheld and
stops receiving structured-output traffic; the next passing check, at most half an hour later,
restores it. Nothing is required of you: your request routes to an endpoint whose promise holds.
A declaration nothing has checked routes normally, since an unverified promise is not a broken one.