Use a strict schema
Set response_format.type to json_schema with a name, strict:true, and the schema. Strict objects require all properties and additionalProperties:false. Nullable fields use a type array, for example ["string","null"]. JSON mode uses {"type":"json_object"}; explicitly ask for JSON in your messages.
{
"type": "json_schema",
"json_schema": {
"name": "readiness",
"strict": true,
"schema": {
"type": "object",
"properties": {
"status": {
"type": "string",
"enum": [
"ready"
]
}
},
"required": [
"status"
],
"additionalProperties": false
}
}
}Supported schema subset
Supported: object, array, string, number, integer, boolean, null, nested anyOf, scalar enums, properties, required, additionalProperties, items, minLength/maxLength, minimum/maximum, minItems/maxItems, title, and description. Root schemas must be objects. Remote/local references, patterns, formats, arbitrary schema keywords, and defaults are rejected. Schemas and compiled validators are request-scoped and are not kept in a process-wide schema cache.
Handle invalid output and refusals
The gateway validates completed JSON. Invalid or truncated structured output returns a safe error and marks the request output_invalid; known provider usage is still charged. A model refusal is returned separately as message.refusal, not parsed as your schema. Streaming consumers must wait for a successful terminal event before treating the completed JSON as valid. Schema validity does not establish factual or clinical accuracy.