Automatic JSON repair
When enabled, RelayOn automatically repairs JSON syntax for non-streaming json_object and json_schema requests. Enable plugins: [{ id: 'response-healing' }] per request, in workspace settings, or for an API key. It is disabled by default, including for existing workspaces. Repair runs before the completion is returned or cached.
What repair can fix
Repair can remove markdown fences or surrounding prose when there is one unambiguous JSON payload, and correct syntax such as unquoted keys, single-quoted strings and trailing commas. Valid JSON is preserved exactly.
Before:
```json
{ok: true, items: [1, 2,],}
```
After:
{"ok":true,"items":[1,2]}Response headers
X-RelayOn-JSON-Repair: unchanged— the original JSON was already valid.X-RelayOn-JSON-Repair: repaired— RelayOn corrected the content’s JSON syntax.X-RelayOn-JSON-Repair: failed— repair could not produce an acceptable JSON value; the original content is returned.X-RelayOn-JSON-Repair: skipped— the response was not eligible for repair.
X-RelayOn-JSON-Repair-Reason accompanies failed or skipped repair. Reasons include plugin_disabled, truncated, streaming, refusal, tool_calls, no_content, size_limit, missing_value, incomplete_string, ambiguous, no_json_payload, wrong_root_type and unrepairable. Requests outside JSON mode report skipped with not_json_mode.
Headers are readable by browser clients and preserved on cache hits. The Responses API uses the same repair statuses.
Limits and unsuccessful repair
Repair does not make another inference request, change token usage or finish reasons, validate schema compliance, or correct factual and calculation errors. For json_object, the result must be an object; arrays, scalar values and null are rejected as the root.
Streaming responses, refusals, tool calls, empty content, responses with finish_reason: length and content longer than 1,048,576 characters are skipped. Missing values, incomplete strings and ambiguous payloads are not filled in with invented data.
Failed or skipped repair returns the original completion with its existing HTTP status. It does not turn a successful inference into an API error. Check the headers, finish_reason and content before using the result; increase the output limit or reduce the requested output when it is truncated.