Prompt Engineering

JSON Mode Prompt — With and Without Native Support

Native JSON modes guarantee syntax, not your schema. The prompt contract that covers field names, types, and null discipline — whether or not the API has JSON mode.

Overview

OpenAI, Claude, and Gemini all offer some form of native structured output — and teams keep getting burned by assuming that solves the problem. Native modes guarantee the response parses; they don't guarantee it contains your field names, your types, or null instead of invented values. The prompt contract still does that work. This resource loads a support-ticket contract that works identically with JSON mode on (where it constrains content) and off (where it also forces syntax) — one prompt, both worlds.

Workflow

Generate the loaded contract
Note what native JSON mode can't do here: the severity value space, the null rule, the no-extra-fields rule.
Pair with your API settings
JSON mode on: keep the schema and validation sections, the syntax rules become redundant insurance. JSON mode off: everything earns its place.
Constrain values in descriptions
The severity field shows the pattern — enumerate legal values in the description and the model treats it as validation.

Why This Works

Separating syntax (the API's job) from schema discipline (the prompt's job) keeps both reliable
Value-space constraints in field descriptions are the cheapest enum enforcement available
One contract across providers means switching models is a config change, not a rewrite

Best for

API developers using response_format or structured output features
Teams running the same prompt on multiple model providers
Anyone who shipped JSON mode and still got wrong field names

Not for

Pure chat use where a human reads the output — the contract is overhead there
Validating responses after the fact — that's the AI Output Validator

Use cases

Writing one prompt that behaves across APIs with and without JSON mode
Constraining value spaces (severity: critical/high/medium/low) that native modes don't enforce
Migrating between model providers without rewriting the output handling

Customize This Resource

Opens this setup in JSON Output Prompt Builder. Generate to get the full output contract — then adjust the schema, format, and strictness.

Open in JSON Output Prompt Builder

Prompt Template

TASK
Convert the customer report in the input into a structured support ticket for our ticketing API.

OUTPUT FORMAT
Return your entire response as a single valid JSON object matching the schema below.

SCHEMA
Each field, its type, and its meaning:
- title (string, required): Short ticket title
- description (string, required): Problem description in the customer's words
- severity (string, required): critical, high, medium, or low
- product_area (string, optional): Affected product area
- reply_needed (boolean, required): Whether the customer expects a reply

EXAMPLE OF A VALID RESPONSE
{
  "title": "Concise descriptive title",
  "description": "Short free-text description",
  "severity": "high",
  "product_area": "standard",
  "reply_needed": true
}

VALIDATION RULES
- Every required field must be present.
- Optional fields with no value: set them to null — do not omit the key.
- Field types must match the schema: numbers without quotes, booleans as true/false.

OUTPUT RULES
- Output only valid JSON — nothing else.
- Do not include explanations.
- Do not include commentary.
- Do not wrap the output in markdown.
- Do not use code fences.
- Return exactly one JSON object.
- Follow the schema exactly — every required field present, no extra fields.
- Use null for unknown values — never invent data.
- No trailing commas.

Related Resources

Explore more resources that work well with this one.