Structured JSON Output from AI Models: Feeding CRMs and Workflows Safely

When an AI model's result flows on into a CRM, a form or an automated workflow, the downstream system cannot read free-form prose. It needs fields with names, data types and permitted values, usually as JSON.

This article draws on current Anthropic and OpenAI documentation on structured outputs, the JSON Schema documentation and 2 OWASP pages, checked on October 23, 2026. None displays an update date.

It covers what the features do, when output still fails to match, and how to check it. Click Star already has separate articles on AI agents, MCP, prompt injection and chatbot evaluation.

Key points

• Structured output forces the model to return data in a predefined shape (which fields, types and values are allowed) so the downstream system does not have to guess.
• Anthropic and OpenAI both constrain output by JSON Schema, but support different subsets. Anthropic's page lists minimum, maxLength and recursive schemas as unsupported; OpenAI's lists minimum, maxItems and recursion as supported.
• Safety refusals, truncation at the token limit and enum capitalization drift can all produce output that does not match the schema (refusals and truncation per both vendors; enum capitalization per Anthropic).
• A valid schema does not mean correct content. OpenAI states that output can still contain mistakes; OWASP recommends treating model output like input from any user.
• What to do: a small schema with an "unknown" exit, read the stop reason first, re-validate on the server, keep a review queue and a sample test set.

Why structured output is needed

Suppose a CRM has a "need" pick list and a "phone number" string. If the model returns "The customer wants skincare advice, call after 5 pm", extra code must guess how to split it.

Anthropic's documentation says that even with careful prompting you can still get invalid JSON, missing required fields or inconsistent types.

JSON Schema as the blueprint for what AI returns

Per the JSON Schema documentation (read October 23, 2026), it describes which fields a JSON record contains and what the values look like. Anthropic and OpenAI both use it to receive the template.

The JSON Schema "object" page lists 2 easily missed defaults. Properties declared under properties are not required unless listed in required. Extra properties are allowed unless additionalProperties is false.

Both vendors make this a hard rule. Anthropic requires additionalProperties to be false on every object. OpenAI's Function calling page also requires all fields in required, with optional ones allowing null.

Design consequence: allow null or an "unknown" value in pick lists, so the model has an exit instead of inventing.

What Anthropic and OpenAI support today

Anthropic. The "Structured outputs" page (read October 23, 2026) describes 2 features usable alone or together. JSON outputs put the schema in output_config.format with type json_schema. Strict tool use sets strict to true on a tool to validate its name and parameters.

The page shows GA status and a supported-model list. The mechanism is constrained decoding: the schema is compiled into a grammar limiting which tokens the model may generate.

OpenAI. The "Structured model outputs" page (read October 23, 2026) says the feature is available from GPT-4o onward, in 2 forms: function calling when the model connects to your tools, and text.format with type json_schema and strict true when the reply follows a template. JSON mode only guarantees valid JSON; Structured Outputs guarantees schema adherence.

Differences to note. Anthropic's page lists minimum, maximum, multipleOf, minLength, maxLength, array constraints beyond minItems of 0 or 1, and recursive schemas as unsupported; using them returns a 400 error. OpenAI's page lists minimum, maximum, minItems and maxItems as supported, and says recursion is supported.

OpenAI notes those properties are not available for fine-tuned models.

Most of Anthropic's SDK helpers strip unsupported constraints from the schema they send, adds them to the description and, in validating helpers, rechecks the response. Both limit schema complexity; Anthropic caps optional parameters at 24 and union-type ones, null types included, at 16 per request, so a small schema helps.

Both add latency the first time a schema is used; Anthropic says compiled grammars are cached for 24 hours from last use.

3 cases where output still fails the schema

Refusals. Per Anthropic's page, when Claude refuses for safety reasons the response has stop_reason of refusal, the HTTP status is still 200, you are billed, and the output may not match the schema.

OpenAI differs: the response carries a separate refusal field. Its page also says the model always tries to follow the schema, so it can invent content when the input is unrelated, and advises stating in the prompt how to handle that, for example by returning empty parameters.

Truncation. With Anthropic it is stop_reason of max_tokens, and the advice is to retry with a higher max_tokens. With OpenAI it is the incomplete status with the max_output_tokens reason in the page's code example.

Anthropic's "Stop reasons and fallback" page says stop reasons arrive in successful responses while errors are HTTP 4xx or 5xx, so, by Click Star's inference, code catching only HTTP errors misses refusals and truncation.

Enum capitalization. Anthropic's page says Claude may return a value that differs from the schema only in capitalization, the response still completes and there is no special stop reason. The advice: compare enum values case-insensitively.

Server-side validation is still required

Matching a schema only guarantees shape (syntax, types, required fields), not that values are acceptable to the business. OWASP's input validation guidance (read October 23, 2026) says to check both syntax and semantics, for example that an end date follows the start date.

OWASP's LLM05:2025 entry calls this Improper Output Handling: model output not checked enough before it reaches other components. It recommends treating the model like any user and using parameterized queries with model output.

Server-side checks for CRM-type data should include:

• Choice values fall within the allowed set (compare case-insensitively).
• Format and length of strings such as phone numbers and emails, per the company's own rules.
• Rules between fields and size limits before parsing (per OWASP).

OWASP also warns about trusting internal sources. An AI result comes from your own system, but its values may originate in a customer's message. Click Star already has an article on prompt injection: a schema does not stop malicious instructions landing in a text field.

A valid schema does not mean correct content

OpenAI's tips section says Structured Outputs can still contain mistakes, and suggests adjusting instructions, adding examples or splitting the task. A schema constrains an answer's shape, not its correctness. A string phone field still gets a string when the message has no number, if null is not allowed.

Click Star suggests 3 layers (a reference framework, not from outside sources). Layer 1 is shape, handled by constraint at generation. Layer 2 is business validity, checked by server code. Layer 3 is truth, which only a source check or a human reviewer can answer.

To ease layer 3, add a quote field: the model copies the exact part of the message it relied on, and the server checks the quote appears in the original. This is Click Star's suggestion, not in either vendor's documentation, and catches only one visible kind of invention.

Illustrative example: a customer message into a CRM

This example was built by Click Star and is not real data. Sample message: "I'm Lan, I'd like advice on a skincare plan for 2 people. Call me after 5 pm, number 0900 000 000."

A suggested schema, with every field listed in required and fields that may lack information allowing null:

• ten_khach, so_dien_thoai, thoi_diem_lien_he: string or null.
• nhu_cau: one of tu_van, bao_gia, ho_tro, khieu_nai, khac, khong_ro.
• can_nguoi_duyet: true or false, set to true when the model is unsure.
• trich_dan: the exact text copied from the message as the basis for nhu_cau.

Flow: read the stop reason; if normal, parse the JSON, validate the schema with Pydantic or Zod plus business rules, and check that trich_dan appears in the original message. If any step fails or can_nguoi_duyet is true, send it to a staff review queue instead of the CRM. Name and phone number are personal data, so send only what is needed.

Click Star's view. Structured output solves one thing: it makes the shape of the data trustworthy so downstream code does not have to guess. It does not replace business validation, manual review or quality measurement.

A common risk is believing the word "guarantee" and dropping validation. Click Star offers AI integration and CRM services, so it has a related interest; this view rests on the cited documentation, not on a specific project.

Testing with a sample set

OpenAI recommends creating evals to choose the structure, and CI rules that flag when the schema or the code's types are edited, or generating the schema from the types.

A sample set is a list of inputs with answers written in advance, rerun whenever the schema, prompt or model changes. These groups are a Click Star reference framework, not from outside sources.

• Normal: a complete message, a missing phone number, 2 needs, no diacritics or abbreviations.
• Hard inputs: an unrelated message, a very long one, one with instructions aimed at the model, one in another language.
• System faults: a low token limit to force truncation, a simulated refusal, enum capitalization drift, broken JSON.

The sources give no sample size or standard threshold; the business sets its own by the cost of one wrong record.

The Vietnamese context

Click Star found no public Vietnam measurement of structured output use or of error rates in AI-returned data, so it gives no market figures. For Vietnamese, test messages without diacritics, abbreviations and mixed English with your own data.

Click Star already has an article on bringing AI into a business with data safety; this article does not give legal advice.

A 14-day plan

This is a Click Star reference framework, not taken from outside sources.

• Days 1 to 2: pick 1 small flow, list the CRM fields needed and which may be null.
• Days 3 to 4: write the schema from your vendor's page and check its unsupported list.
• Days 5 to 7: build the server-side validation layer, stop-reason handling and a manual review queue.
• Days 8 to 10: build a sample set in 3 groups, run it and record the failures.
• Days 11 to 14: run in parallel with a person working by hand, then decide the level of automation.

How to measure: the share going to the review queue, the refusal or truncation rate, the records staff must correct and the first-use latency of a new schema.

What is not known

Click Star has no independent measurement of the real error rate of structured output. The documents read come from the vendors and display no update date.

Click Star has not run API code to measure latency, truncation or refusal rates, and has not read other vendors. The sources hold no measurement of Vietnamese extraction quality. The CRM example and 3-layer framework are inference.

Common mistakes

1. Only writing "return JSON" in the prompt and parsing directly, without using the vendor's schema constraint.
2. Believing that once the constraint is on, checking is unnecessary, despite documented refusals, truncation and enum capitalization drift.
3. Catching only HTTP errors without reading the stop reason or response status.
4. Making every field required but not allowing null or "unknown", pushing the model into inventing.
5. Applying one vendor's feature list to the other, for example using minimum or recursive schemas with Anthropic.
6. Writing AI results straight into the CRM or into queries, without validation or a review queue.
7. Having no sample set, so a model or schema change goes ahead without knowing how quality changed.