A JSON response that fits the next step

A language model can read a support message and explain what the customer needs. But if your application needs to route that message, a paragraph creates extra work. You need predictable fields: a category, a priority, and perhaps an order number.

Structured JSON output makes that handoff easier. Instead of asking only for an answer, you also describe the shape the answer should take. Your application can then read the result as data.

§ A small example from a support inbox

Suppose a customer writes: “My order AB-204 arrived with a broken handle. Can you send a replacement?” You want your application to classify the request before someone reviews it.

A useful response might look like this: {"category":"damaged_item","priority":"normal","order_id":"AB-204"}.

Each field has a clear job. The category determines the queue, the priority helps sort it, and the order identifier connects the message to an existing record. Keeping those names and value types consistent lets ordinary application code handle the next step.

JSON is a data format, not a guarantee of accuracy. A response can have perfect punctuation and still contain the wrong order number. Structure makes an answer easier to process; it does not make every extracted fact correct.

§ Give the response a defined shape

The simplest approach is to ask for JSON in your prompt. Explain the fields, show an example, and tell the model to return only the object. This can work for experiments, but a prompt alone does not reliably enforce the format.

Some APIs offer a JSON mode that constrains the response to valid JSON. Some also support structured output using a JSON Schema, which describes the permitted fields and values. Availability and supported schema features depend on the model and API route.

For the support example, your schema could require three properties:

• category: a string chosen from a small set, such as damaged_item, delivery_question, or other.
• priority: a string limited to normal or urgent.
• order_id: a string when an identifier is present, or null when it is missing.

You can also forbid additional properties where supported. This keeps an unexpected field from quietly becoming part of your application's contract.

Start with the smallest schema that serves the task. Every extra field adds something the model must infer and your application must check.

§ Leave room for missing information

Real messages are incomplete. A customer might say “my order” without providing a number. If your instructions demand a string for every field, the model may fill the gap with an unsupported guess.

Define how missing information should appear. Depending on the task, that might mean null, an empty list, or an explicit unknown value. Explain that the model should extract facts from the supplied message and leave unavailable facts unset.

Use clear category definitions, too. If urgent means a safety issue, say so. Without that definition, the model has to supply its own interpretation.

§ Check the result before using it

Your application should parse the response, validate it against the expected schema, and apply any business rules. An order identifier can be a valid string while still failing to match an order in your database.

Also handle responses that cannot be used: a refusal, a token limit that cuts the output short, or an API error. Check the response status before treating its content as a complete object. If you retry, use a bounded retry policy and avoid repeating actions such as sending a replacement.

§ Trying it through Vana API

Vana API provides an OpenAI-compatible endpoint at https://api.vanaapi.com, alongside support for the Anthropic Messages and Gemini native protocols. You can use an OpenAI SDK for a small extraction experiment, while checking which structured-output options your selected model and route support.

Create a Vana API account to try a small set of representative messages, with usage billed per real token and no monthly fee. Include missing order numbers, ambiguous requests, and messages outside your categories. Review both whether the JSON validates and whether its contents match the message.