Overview
Structured outputs allow you to constrain the model’s response to follow a specific JSON schema. This ensures the model returns data in a predictable format that can be reliably parsed and processed by your application.
To avoid JSON parse errors, add post_processing_steps: [{"type": "json-repair"}] to your request. The LLM Gateway will automatically repair common JSON errors before returning the response. See Post-processing.
Getting started
To use structured outputs, include the response_format parameter in your request with a json_schema type:
Example response
When using structured outputs, the model’s response will be a JSON string that conforms to your schema:
You can parse the content as JSON in your application:
Supported models
Structured outputs are supported by the following model families:
| Provider | Supported |
|---|
| OpenAI (GPT-4.1, GPT-5.x) | Yes |
| Gemini | Yes |
| Claude (4.5+) | Yes |
| Alibaba Cloud Qwen | Yes |
| Moonshot AI Kimi | Yes |
| gpt-oss | No |
Post-processing
Post-processing steps let you apply automatic fixes to model responses after generation. You can specify an ordered list of steps in the post_processing_steps parameter on any chat completions request. Steps run server-side on all LLM Gateway models in both US and EU regions.
Currently, JSON repair (json-repair) is the only supported step type.
JSON repair
JSON repair corrects common JSON errors — such as trailing commas, unescaped characters, and missing quotes — that LLMs occasionally produce. This is especially useful when using structured outputs or tool calling, where invalid JSON would otherwise require client-side retry logic.
Getting started
Add post_processing_steps to any chat completions request:
What JSON repair fixes
The JSON repair step corrects the most common JSON errors produced by LLMs:
| Error type | Example (broken) | After repair |
|---|
| Trailing comma | {"name": "John",} | {"name": "John"} |
| Unescaped characters | {"note": "say "hi""} | {"note": "say \"hi\""} |
| Missing closing bracket | {"name": "John" | {"name": "John"} |
| Single-quoted strings | {'name': 'John'} | {"name": "John"} |
The step applies to both message content and tool call arguments in the response. post_processing_steps runs independently of response_format, so you can combine JSON repair with a json_schema for maximum reliability.
If the JSON cannot be repaired, the request returns an HTTP 500 error. The raw malformed response is never passed through.
API reference
Request parameters
The response_format parameter controls how the model formats its response:
| Key | Type | Required? | Description |
|---|
response_format | object | No | Specifies the format of the model’s response. |
response_format.type | string | Yes | The type of response format. Use "json_schema" for structured outputs. |
response_format.json_schema | object | Yes | The JSON schema configuration object. |
JSON schema object
| Key | Type | Required? | Description |
|---|
json_schema.name | string | Yes | A name for the schema. Used for identification purposes. |
json_schema.schema | object | Yes | A valid JSON Schema object that defines the structure of the expected response. |
json_schema.strict | boolean | No | When true, the model will strictly adhere to the schema. Recommended for reliable parsing. |
Schema definition
The schema object follows the JSON Schema specification. Common properties include:
| Property | Type | Description |
|---|
type | string | The data type: "object", "array", "string", "number", "boolean". |
properties | object | For objects, defines the properties and their schemas. |
items | object | For arrays, defines the schema for array items. |
required | array | List of required property names. |
additionalProperties | boolean | When false, prevents additional properties not defined in the schema. |
Post-processing parameters
| Key | Type | Required? | Description |
|---|
post_processing_steps | array | No | An ordered list of post-processing steps to apply to the response. Omit to disable post-processing. |
post_processing_steps[i].type | string | Yes | The step type. Currently "json-repair" is supported. |
Supported step types:
| Type | Applies to | Models | Regions |
|---|
json-repair | Message content and tool call arguments | All LLM Gateway models | US and EU |
Best practices
When using structured outputs, keep these recommendations in mind:
Set strict: true to ensure the model’s response strictly adheres to your schema. This is especially important when your application depends on specific fields being present.
Use additionalProperties: false at each level of your schema to prevent the model from adding unexpected fields to the response.
Keep your schemas focused and specific. Complex schemas with many nested levels may increase latency and token usage.
Include clear descriptions in your system or user messages to help the model understand what data to extract or generate for each field.
Error handling
If the model cannot generate a valid response that matches your schema, you may receive an error or a response that doesn’t fully conform to the schema. Always validate the parsed JSON against your expected structure: