Structured Outputs
JSON mode still drifts. Production parsers need required keys and enums, not 'almost JSON'.
A typed form with dropdowns, not a blank page labeled JSON.
Visual Workflows
Start here — scroll inside each diagram frame to explore, then use + / − to zoom up to 200% if needed.
Overview
Scroll inside the frame to explore · use + / − to zoom up to 200%
Scroll inside the frame to explore · use + / − to zoom up to 200%
From schema to object
Scroll inside the frame to explore · use + / − to zoom up to 200%
You declare the shape. The API returns an object that fits.
Key Takeaways
- 1.Structured outputs constrain the reply to a JSON Schema you define. Enums, required fields, and nested objects can be guaranteed.
- 2.Use this when code will crash on a wrong shape. Tool args are a schema too — same idea, different slot.
- 3.Pass a schema (or a Pydantic/Zod model) as the response format. The provider constrains decoding.
- 4.Still handle refusals. Tool parameters use the same schema idea.
Learn elsewhere
- →JSON Mode
- →Tool Validation
Real Example
Scenario
Schema requires status: enum[open,closed] and ticket_id: string. The model cannot return 'kinda open'.
What you would do
In Tool Calling & Function Calling, apply Structured Outputs to this scenario: Schema requires status: enum[open,closed] and ticket_id: string. Identify the inputs, run the technique, validate the output, and note one thing you would monitor in production.
Commands
Commands to Remember
Schema = contractRequired + enumsWorks for answers and tool argsHandle refusals
Cheat Sheet
Quick recap
quick ref- •Typed form
- •Stronger than JSON mode
- •Same idea as tool params
- •Still handle refuse
Common Mistakes
- ✕A schema so huge the model refuses
- ✕Skipping a fallback when the provider cannot constrain
- ✕Confusing JSON mode with structured outputs