HTTP Request Node - JSON-RPC Error: "Missing 'model' or 'method' in 'params' object" Despite Correct Input

[Lorena_Lopez]

Hello everyone,
I’m hoping to get some help with a very strange issue in a production workflow that was working perfectly until yesterday. I’m consistently receiving a JSON-RPC error from my custom API endpoint, but the input data within n8n right before the request is sent appears to be perfectly correct.
Here’s a summary of the setup:
A Webhook receives a request.
A Code Node (“Prepare Parameters”) defines the query parameters (model, method, domain, etc.).
A second Code Node (“Build Body”) uses these parameters to construct a standard JSON-RPC request body.
An HTTP Request Node sends this body to our custom backend API.
The Problem:
The API consistently responds with the following error:
JSON
{“error”: “Missing ‘model’ or ‘method’ in ‘params’ object”}
This error clearly suggests that the params object in the request body is missing the required keys.
The Contradiction / The Core Issue:
Here is the critical part that I cannot solve: when I inspect the Input data of the final HTTP Request node in the n8n editor, the request body being prepared is perfectly formed.
The input data shows an object where the params key contains both the model and method keys with the correct string values, along with all other necessary data. The data is 100% correct right before it’s sent, but the server claims the data is missing.
Debugging Steps Already Taken:
I have been debugging this for many hours and can confirm the following:
The workflow is generating the correct JSON object. The input panel of the HTTP Request node is my proof.
Authentication is working. I am receiving a 200 OK response with an application-level error, not a 401 Unauthorized or 403 Forbidden error.
The n8n Code nodes have been checked exhaustively for syntax errors (typos, commas, quotes, invisible characters) and logical errors. We even restored a previously working version of the code, and the error persists.
The HTTP Request node is configured to send application/json with the Body expression {{ JSON.stringify($json.solBody) }}.
My Question for the Community:
Has anyone ever encountered a situation where the Input of an HTTP Request node shows a perfectly valid object, but the receiving server acts as if that object is malformed?
Is there any subtle setting, known bug, or caching mechanism in n8n that could cause the JSON body to be altered or corrupted between the final input preparation and the actual HTTP transmission?
Any ideas would be greatly appreciated, as I’m completely stuck on how to proceed. This was a stable, working system until yesterday.
Thank you for your time and help.

[jabbson]

Hey @Lorena_Lopez hope all is well.

If you open the Dev Web Console you can actually inspect the request that is being sent out. See if looking at this request can shed any light onto what the issue could be.

[darrell_tw]

Might need to take a look on the preview about your final HTTP Request node

Maybe you see the object is correct in Input.

But there is a chance need something like obj.toJsonString() to parse as Json String.

[Lorena_Lopez]

Hello everyone,

I’m happy to report that this issue is now solved! Thank you all so much for your suggestions, which were crucial in helping me isolate the problem.

The final diagnosis was that our custom backend API server was unpredictably running an old, cached version of its code. This old code expected a different JSON structure than the new code. Critically, even a server restart did not reliably clear this cache, making the endpoint’s behavior unstable.

The Solution: A Dual-Format Workaround in n8n

Since we couldn’t rely on which version of the code the server would execute, we implemented a robust workaround entirely within n8n to handle both scenarios simultaneously.

1. Building a “Universal” Request Body:

In the Code node that builds the HTTP request, we modified the final JSON object to include the required parameters in two places: at the root level of the JSON-RPC object (to satisfy the old, buggy code) and correctly nested inside the params object (to satisfy the new, correct code).

Example:

JSON

const finalBody = {
    "jsonrpc": "2.0",
    "method": "call",

    // Format 1: For the old/cached server code
    "model": model,
    "method": method,
    "args": args_to_use,
    "kwargs": kwargs_to_use,

    // Format 2: Standard format for the new/correct server code
    "params": {
        "model": model,
        "method": method,
        "args": args_to_use,
        "kwargs": kwargs_to_use
    }
};

2. Creating a Flexible Response Parser:

In our final Code node that processes the API’s response, we also updated it to flexibly check for the results in multiple possible locations (result, body.result, or the root of the input object).

The Outcome

This dual-format strategy works perfectly. The system is now stable and the request succeeds regardless of which version of the code the server is running. It’s a client-side (n8n) fix that makes our workflow resilient against these server-side deployment/caching issues with minimal overhead.

I wanted to share this solution in detail in case anyone else ever runs into a similar “ghost in the machine” caching problem with a backend service. Your help was invaluable in confirming that our n8n logic was sound, which ultimately led us to this creative workaround.

Thanks again!