JSON Repair Prompt Template for API Payloads

This prompt is for backend engineers and platform teams who receive broken JSON from model-generated API responses. It repairs the most common structural failures: missing commas between key-value pairs, trailing commas after the last element, unescaped double quotes inside string values, and mismatched bracket or brace counts. Use this prompt when a downstream JSON parser rejects the model output and you need a programmatic repair step before retrying the original generation.

This is a post-generation repair loop, not a schema enforcement tool. If the model output violates a target JSON Schema, use the Schema Validation Failure Repair Prompt instead. If the JSON is embedded in markdown fences, use the Markdown Code Block Extraction Prompt first. The repair prompt works best on structurally broken but semantically intact JSON—it cannot recover content that was never generated or fix deeply nested structural corruption where the intended hierarchy is ambiguous.

Wire this prompt into your application's error-handling path: catch JSON.parse failures, extract the raw string, inject it into the [BROKEN_JSON] placeholder, and attempt repair before falling back to a full regeneration request. Always validate the repaired output with a parse attempt and compare against your expected schema. For high-throughput pipelines, add a repair attempt counter to avoid infinite loops and log repair success rates to monitor model output quality over time.

This template is designed to be the core instruction set for a repair loop. It expects a malformed JSON string and a target JSON Schema, and it instructs the model to produce a strictly valid, schema-conforming output. The prompt uses square-bracket placeholders so you can inject the specific payload, schema, and operational constraints at runtime without modifying the core instruction text. Use this template as the system or user message in your repair harness, directly after a parser or schema validator has rejected the original model output.

textCopy
You are a JSON repair specialist. Your task is to fix a malformed JSON payload so that it becomes valid JSON and strictly conforms to the provided JSON Schema.

# INPUT
[MALFORMED_JSON_PAYLOAD]

# TARGET SCHEMA
[TARGET_JSON_SCHEMA]

# REPAIR RULES
1. Parse the input and identify all syntax errors (e.g., missing commas, trailing commas, unescaped characters, mismatched brackets, single quotes instead of double quotes).
2. Identify all schema violations (e.g., wrong types, missing required fields, extra fields not in the schema, incorrect enum values).
3. Repair the JSON to fix all syntax errors and schema violations.
4. For ambiguous repairs (e.g., a string "123" in a number field), coerce the value to the correct type. If coercion is impossible, set the field to `null`.
5. Do not add, remove, or change any data beyond what is necessary to achieve valid, schema-conforming JSON. Preserve all recoverable information.
6. If the input is completely unrecoverable, output a valid JSON object with a single key `"repair_error"` containing a string description of the failure.

# CONSTRAINTS
[ADDITIONAL_CONSTRAINTS]

# OUTPUT FORMAT
Return ONLY the repaired JSON object. Do not include any explanatory text, markdown fences, or code blocks. The output must parse with a standard JSON parser.

To adapt this template, replace each square-bracket placeholder with the appropriate data for your current repair attempt. [MALFORMED_JSON_PAYLOAD] should be the raw string that failed validation. [TARGET_JSON_SCHEMA] should be the complete JSON Schema object the output must satisfy. [ADDITIONAL_CONSTRAINTS] is optional and can be used to inject field-specific rules, such as a map of enum values or a null-representation policy. After populating the placeholders, send this prompt to the model. The output should be a clean JSON object ready for re-validation. Always run the model's output through a JSON parser and schema validator before accepting it. If validation fails again, feed the new error and the model's output back into the repair loop with an updated [MALFORMED_JSON_PAYLOAD], up to your configured retry limit.

The JSON repair prompt is not a standalone fix; it is a component inside a repair loop. The application should first attempt to parse the model's raw output. If JSON.parse() or an equivalent schema validator fails, capture the exact error message, line number, and a snippet of the malformed JSON around the failure point. Feed these diagnostics into the prompt's [MALFORMED_JSON] and [PARSE_ERROR] placeholders rather than sending the entire raw output with no context. This targeted input dramatically improves repair accuracy and reduces token cost.

Wrap the prompt call in a retry controller with a hard limit—typically 3 attempts. On each iteration, validate the repaired output against the expected [OUTPUT_SCHEMA] using a JSON Schema validator like ajv. If validation passes, break the loop and return the payload. If it fails, feed the new parse error back into the next repair attempt. After the final retry, if the output is still invalid, do not guess. Log the failure with the original input, all repair attempts, and the final error. Escalate to a dead-letter queue or a human review interface depending on the [RISK_LEVEL] configured for the workflow.

For API payload repair specifically, add a structural diff step after successful repair. Compare the repaired JSON against the original malformed input to produce a list of changes: added commas, removed trailing commas, escaped quotes, balanced brackets. This diff serves dual purpose: it provides an audit trail for debugging model behavior and can be surfaced to human reviewers when the repair confidence is borderline. Store the diff alongside the repaired payload in your observability system.

Choose your model based on the complexity of the repair, not just cost. For simple fixes like missing commas or unescaped strings, a fast, cheap model like GPT-4o-mini or Claude Haiku works well. For deeply nested structural corruption, bracket imbalances across multiple levels, or repairs where field-level type coercion is required, use a more capable model like GPT-4o or Claude Sonnet. Implement model routing in your harness: attempt the first repair with a fast model, and escalate to a stronger model only if the first attempt fails validation.

Log every repair attempt with structured metadata: original_length, repair_attempt_number, model_used, parse_error_type, validation_result, tokens_consumed, and repair_diff. This telemetry lets you measure repair success rates by error category, identify recurring failure patterns that need prompt improvements, and track cost per successful repair. If a specific error type—like trailing commas in nested arrays—shows a repair success rate below 90%, invest in improving the prompt's handling of that case or add a pre-processing regex step before the LLM call.