n8n HTTP Request: Fix “JSON Parameter Needs to Be Valid JSON”

How do you fix ‘JSON parameter needs to be valid JSON’ in n8n?

Set Body Content Type to JSON, then choose one valid boundary. Keep a literal body as valid JSON after every expression resolves, or make the entire field an expression that returns an object. n8n's official common-issues page recommends wrapping a whole JSON object in double curly brackets when you use an expression.

Do not change credentials, retry settings, or the endpoint yet. This validation error happens while n8n parses the JSON Body, before the request can reach the API. Fix the body first, run one known input, and inspect the evaluated value.

Fastest repair: test a static body, add dynamic fields back one at a time, and stop at the first value that introduces an unescaped quote, newline, comma, bracket, or stringified object.

The common causes are unquoted keys, smart quotes, a missing comma, an expression placed outside a JSON value, dynamic text that contains quotes or line breaks, and an object that was converted into a string.

Current n8n source parses the JSON Body before building the request and reports invalid JSON at that boundary. Older versions and community reports often show the wording ‘JSON parameter needs to be valid JSON’. The current source uses ‘The value in the JSON Body field is not valid JSON’. See the HTTP Request node source.

What should you test before rebuilding the request?

Replace the body with one static object that the target API accepts. If that runs, the endpoint, method, credentials, and content type are far less likely to be the immediate cause. Restore one dynamic field at a time until the validation error returns.

Pin one representative input item for the test. A body that works for item 0 can still fail on item 1 when a customer name, transcript, or AI output contains a quote or newline.

Why does n8n say the JSON parameter is not valid?

n8n cannot parse the evaluated JSON Body into an object. The text may look valid in the editor, but the value produced for a real item can still contain broken quoting, a trailing comma, an expression in the wrong place, or a string where the node expects an object.

Start with these checks:

Use straight double quotes around JSON keys and string values. Smart quotes copied from a document are not valid JSON.

Remove trailing commas. Every opening brace or bracket needs a matching closing brace or bracket.

Evaluate the body with the same input item that failed. Inspect the output, not only the expression syntax shown in the editor.

How do you keep a literal JSON body valid?

Keep the surrounding body as JSON and serialize dynamic string values at the value boundary. This is useful when most of the payload is fixed and one field can contain quotes or line breaks.

Broken: { "message": "{{ $json.output }}" }

Safer: { "message": {{ JSON.stringify($json.output) }} }

When should the whole body be an object expression?

Use one expression for the entire body when several fields are dynamic or when you need nested objects and arrays. Return an object directly. Do not wrap that object in quotes or stringify it before the HTTP Request node receives it.

Whole-body expression:

{{ { "message": $json.output, "executionId": $execution.id, "tags": $json.tags ?? [] } }}

An n8n maintainer documented this object-expression pattern in issue #15996. That issue was closed as stale, so treat it as syntax guidance and historical evidence, not proof of a current unresolved product bug.

After the expression evaluates, the field should be an object. If the preview shows one quoted string containing braces, you still have a string/object boundary problem.

When does JSON.stringify help, and when does it hurt?

Use JSON.stringify for one dynamic value inside a literal JSON body. Do not stringify the whole object when the node expects an object, because that turns the payload into a JSON-looking string.

Value boundary: { "message": {{ JSON.stringify($json.output) }} }

Object boundary: {{ { "message": $json.output } }}

Wrong boundary: {{ JSON.stringify({ "message": $json.output }) }}

If the API needs a raw JSON string rather than an object, use Raw body mode and the exact Content-Type the API documents. That is a different request shape from JSON body mode.

How do you verify the JSON repair?

Run the node with one pinned item, confirm the validation error disappears, inspect the outgoing body or echoed test response, and compare it with the API's required schema. Then test an input containing a quote, newline, empty value, array, and nested object before returning the workflow to production.

A green node run is not enough. Verify the target service accepted the intended field types and values, then rerun the full workflow and inspect the next node's input.

What do three common broken bodies look like?

Why does an unquoted expression fail?

An expression inserted as bare text can leave the evaluated body outside valid JSON syntax.

Broken: { "prompt": {{ $json.prompt }} }

Fixed for a string value: { "prompt": {{ JSON.stringify($json.prompt) }} }

Why does concatenation inside JSON fail?

JavaScript concatenation is not valid inside a literal JSON value. Either keep the result inside one evaluated string value or return the whole payload as an object expression.

Broken: { "id": "run-" + {{ $execution.id }} }

Fixed as an object expression: {{ { "id": "run-" + $execution.id } }}

Why can item 1 fail when item 0 passes?

Each input item evaluates the body separately. A later item can introduce a quote, newline, null, array, or object that the first item did not contain.

Test: plain text, text with a double quote, text with a newline, an empty string, null, an array, and a nested object.

If only one case breaks, fix the value boundary for that type. Do not hide it with retries, because the same item will fail again.

How do you separate JSON validation from an API error?

The JSON validation error occurs before the request is sent. HTTP 400, 401, 403, 429, and 5xx responses come from the target API after it receives a request. Fix the parser boundary first, then diagnose the response code.

400 Bad Request means the API rejected the request shape or values. Compare the evaluated body with the service's schema.

401 Unauthorized and 403 Forbidden are credential, scope, or policy failures unless current evidence shows a node-specific case. Do not rewrite the JSON to fix an authentication response.

429 Too Many Requests is a rate-limit response. Use the API's retry window, batching, and bounded retries after the request body is proven valid.

ECONNREFUSED means the network reached a host but nothing accepted the connection on that port. On self-hosted n8n, container networking and localhost are common causes. Follow n8n's official ECONNREFUSED checks.

‘Response body is not valid JSON’ is a different parser boundary. If the API returns text, set Response Format to Text instead of forcing JSON.

A timeout means n8n did not receive response headers within the configured window. It does not prove the JSON body was invalid.

The official HTTP Request documentation covers JSON body mode, response handling, pagination, batching, and timeout options.

Frequently asked questions

Why does the JSON look valid in the editor but fail at runtime?

A dynamic value can introduce a quote, newline, null, array, or object only when the real item is evaluated. Pin the failing input and inspect the evaluated body for that item.

Should I put quotes around an n8n expression in JSON?

For a simple string, serialize the dynamic value at the value boundary. For a whole dynamic payload, return one object expression. Do not add an extra pair of quotes around a serialized value.

Can I use Using Fields Below instead of Using JSON?

Yes. Using Fields Below is often safer for a flat payload because n8n owns the object structure. Use Using JSON when you need nested objects, arrays, or an exact body shape.

Why does my version show different wording?

Older n8n reports commonly show ‘JSON parameter needs to be valid JSON’. Current source uses ‘The value in the JSON Body field is not valid JSON’. Both point to the body-parsing step, but the exact wording can vary by version.

What proves the repair is complete?

The node must send the intended object, the API must accept the field types and values, and the full workflow must complete with the expected downstream result. Save the failing input and the verified rerun as the rollback and regression test.

If the JSON parses but the production workflow still fails, use Synta to inspect the execution, repair the live workflow, rerun it, and verify the result.