LLM structured outputs for SaaS: schemas, refusals and validation
Use provider-supported JSON schemas to shape model responses, then validate meaning, authorization and edge cases before your SaaS application stores data or takes action.
In this guide
What are structured outputs, and when should a SaaS app use them?
Structured outputs constrain a model response to a supported schema, such as an object with required fields and enumerated values. They make an integration easier to parse, but they do not prove that a response is true, authorized or safe. Use them when your application needs a stable data contract, and verify provider support, refusal behavior and incomplete-response handling for the exact model and endpoint.
Choose a response schema for data and function calling for actions
Use a structured response format when the model is returning data your application will display or process. Use a tool or function call when it is proposing an operation for the application to consider. A valid tool-call argument is still only a request: authenticate the user and independently authorize the exact action on your server before executing it.
Treat provider schema support as a documented subset
JSON Schema implementations differ. A provider may support only certain types, constraints, nesting patterns or strict-mode combinations, and support may depend on model and API version. Keep a small compatibility suite for each production route. Do not assume a schema that passes your local validator will be accepted unchanged by every provider.
Design clear fields and explicit uncertainty states
Use descriptive property names, short field descriptions and bounded enums for decisions that have a known set of outcomes. Include an explicit unknown or needs-review state when source material may be insufficient. If every field is forced to contain a confident value, a constrained model can invent content just to satisfy the shape.
| Use case | Schema and version | Provider/model support | Semantic checks | Refusal and failure behavior |
|---|---|---|---|---|
How do you validate model output before using it?
Check completion state before parsing content
Handle refusals, token-limit truncation, incomplete tool arguments, content-filter outcomes and transport errors as distinct states. A response can be well-formed JSON but still be incomplete or refused. Do not treat a missing value as permission to guess, and do not trigger a side effect from a partial stream.
Validate both the shape and the business meaning
Parse with a trusted library, enforce size and range limits, and reject fields the application does not recognize when forward compatibility permits. Then verify business rules against trusted records: tenant ownership, current status, allowed currency, permitted destination and state transitions. A schema validator cannot replace object-level authorization or domain validation.
Keep a single source of truth for code types and schemas
Where an SDK supports generating a request schema from your typed model, use that path or add a CI check that compares the maintained schema and application type. Review schema changes like API changes: identify required-field additions, enum changes, maximum lengths and how older clients or stored records will be handled.
How do you release structured-output changes safely?
Pin the complete response contract
Record the provider, endpoint, model identifier, schema version, prompt revision, parser version and downstream consumer with each release. A model or SDK alias can change independently from your schema. Keep the exact response path reproducible without retaining customer prompts or answers longer than your approved policy allows.
Test realistic edge cases and semantic errors
Build examples for valid answers, missing evidence, refusals, non-English input, conflicting instructions, long values, unexpected but parseable values and malicious strings. Assert both successful parsing and safe denial. Run representative evaluations after changing a model, schema, prompt, parser or provider route.
Do not retry invalid meaning into an approved action
A bounded retry may help with a transient format or transport failure when the provider supports a safe retry. It cannot turn an unauthorized or unsupported request into a valid action. Preserve the original failure category, avoid multiplying attempts at several layers, and route consequential ambiguity to a human or a clear user correction flow.
LLM structured outputs: FAQs
Does JSON mode guarantee my schema?
No. JSON mode generally targets valid JSON syntax. Schema-constrained structured output is designed to match a supported schema, but the feature, model support and edge cases vary by provider. If a route cannot enforce the schema, validate locally and handle failure explicitly.
Does a schema guarantee that the answer is correct?
No. It constrains shape and allowed values, not evidence or truth. Check source support, business rules, tenant permissions and user impact separately.
Should a model be allowed to call a tool because its arguments match a schema?
No. Schema validation checks argument structure. Your backend must still bind the call to the authenticated user and tenant, authorize the requested object and operation, and apply normal transaction and idempotency controls.
Why might a provider reject a schema that validates locally?
The API may implement a limited JSON Schema subset or impose model-specific constraints. Check the provider's current documentation, test the exact request during deployment validation, and keep a compatible fallback that still performs application-side validation.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- Structured model outputsOpenAI API documentation
- Structured outputGoogle AI for Developers
- LLM05:2025 Improper Output HandlingOWASP Gen AI Security Project
- Evaluation best practicesOpenAI API documentation
- Error codesOpenAI API documentation
- Production best practicesOpenAI API documentation
- OWASP API Security Top 10: API1:2023 Broken Object Level AuthorizationOWASP Foundation