In this article
A schema defines the output contract; it does not make extracted facts true or eliminate refusal and incomplete-output handling.
For structured JSON through OpenRouter, use the structured-output mechanism supported by the selected model and endpoint. Asking for JSON in ordinary text describes an intention but does not replace a schema or application validation. The request structure also differs between Chat Completions and Responses.
Start with a small contract
Define a few required fields, clear types and allowed values. For a test equipment offer, you might extract a string gpu_model, an integer count and an explicit indication that a fact is unknown. Do not require the model to invent a quantity when the source never supplies one.
A complicated schema with many alternatives makes a first integration harder to diagnose. Keep a versioned example document and expected result. This gives the team an objective control when changing the model, prompt or application, rather than judging success by whether the output looks organized.
Confirm support on the actual route
A model can be served through different providers. A feature mentioned in a model description does not establish identical support on every endpoint. Check the chosen route with the required parameters, and configure selection so that a missing compatible destination produces an understandable failure.
Do not silently weaken a mandatory output contract when a fallback lacks support. A normal text response from a similar model is not equivalent evidence. Test one synchronous request first, then add streaming or tools independently so the failing feature remains identifiable.
Use the correct API field
| Operation | Schema configuration |
|---|---|
| Chat Completions | response_format with JSON Schema |
| Responses | text.format with JSON Schema |
| Ordinary text instruction | An instruction without an equivalent structural contract |
Do not copy an entire settings object between protocols. Check the operation’s documented body and inspect the request your client actually sends. A gateway may transform configuration, so preserve the external operation and schema version in the test record.
Validate structure and evidence
First validate JSON syntax and schema compliance: required fields, types, ranges and unexpected properties. Then validate meaning against the source. Was that GPU actually named? Are memory units correct? Does the quantity correspond to the offer rather than a nearby example?
For important fields, preserve a reference to the relevant source fragment and allow unknown values. Structured output can still contain a well-formed guess. Test missing quantities, ambiguous names, conflicting statements and truncated input. Also test refusal and an answer stopped by its output limit; neither should become an accepted inventory record.
Version the schema alongside results so old records are not silently reinterpreted after a contract change. Extraction may help draft the information, while the owner confirms the actual hardware and available operating conditions.
Official references: openrouter.ai — structured outputs, openrouter.ai — provider selection.
Related guides: Tool calling through OpenRouter: the model proposes, your app executes, Setting up an OpenRouter API key for an application.