# Pattern: JSON Escaping for Downstream APIs

## Symptom
An n8n workflow passes LLM-generated text into a downstream API call, and the request fails with a JSON parse error, malformed payload, or unexpected truncation. The generated text contains quotes, newlines, backslashes, emojis, or control characters that break JSON encoding.

## Affected Projects
- LinkedIn content automation (LinkedIn REST API posts)
- AI video generation pipeline (ComfyUI / JSON2Video payloads)
- Any n8n workflow that injects LLM output into an HTTP Request node body

## Root Cause
LLMs produce human-readable text; downstream APIs consume machine-readable JSON. Naive string concatenation or weak JSON serialization allows unescaped characters to corrupt the payload. The failure often appears at the receiving API, making root-cause diagnosis slower.

## Standard Fix
1. Treat LLM output as untrusted string data.
2. Always serialize it through a proper JSON encoder (`JSON.stringify` in JS, `json.dumps` in Python) before embedding in a payload.
3. If building a payload string manually, escape quotes, backslashes, newlines, and control characters; better, avoid manual string building entirely.
4. Add a validation step that parses the final payload with `JSON.parse` before sending.
5. For n8n, prefer expression mapping through structured fields rather than raw body strings.

## When to Apply
- Any new integration where LLM-generated content becomes part of an API request body.
- Any HTTP Request node in n8n that builds a JSON body from expressions containing LLM output.

## Verification
- Test with adversarial LLM output containing quotes, newlines, unicode, and backslashes.
- Confirm the receiving API parses the payload correctly.
- Log payload shape (without secrets) for debugging.

## Related Patterns
- `ollama-structured-output-fallback`
- `llm-as-parser-fallback`