Structured outputs

Structured outputs let you hand the model a schema, usually JSON Schema or a Zod or Pydantic model that converts to one, and get back output that conforms to it. Instead of asking for JSON in the prompt and hoping, the provider enforces the structure during generation, so required fields are present and types match.

This is what turns a model into a component your code can depend on. Extraction, classification, routing, and any feature that feeds a database, a UI, or another step needs predictable fields, not prose. With an SDK helper you can parse the result straight into a typed object.

Schema-valid is not the same as correct. The model can still put the wrong value in the right field, invent a value where it should have left one empty, or pick a plausible but incorrect category. Design schemas that allow null or unknown, add enum values for edge cases, validate business rules in code, and handle responses that come back empty because of a refusal or a token cap.

Keep schemas small and descriptive. Field names and descriptions are effectively part of the prompt, and an overly nested schema is harder for the model to fill well.