Step by Step Guide to solve n8n Set Node Type mismatch Error
Who this is for: n8n workflow designers who encounter “Type mismatch” errors in Set nodes and need a clear, production‑ready way to resolve them. We cover this in detail in the n8n Node Specific Errors Guide.
Quick Diagnosis
- Open the Set node → Edit the problematic field.
- Click the gear icon → Convert to… and choose the correct type.
- If the value comes from an expression, wrap it with the proper conversion function (
Number(),String(),JSON.parse(), etc.). - Save and re‑run the workflow.
If the error persists, follow the step‑by‑step guide below.
1. What Triggers a “Type mismatch” in a Set node?
If you encounter any n8n merge node type mismatch resolve them before continuing with the setup.
| Trigger | Why it causes a mismatch | Typical error message |
|---|---|---|
| Assigning a string to a field that downstream expects a number | “123” is a string, not a numeric value. | Type mismatch: expected number, got string |
| Using an array where an object is required | Nodes like Google Sheets or Airtable need key/value objects. | Type mismatch: expected object, got array |
| Leaving a field empty (undefined) when a value is mandatory | undefined is a distinct type that most nodes reject. | Type mismatch: expected string, got undefined |
| Mixing JSON strings with parsed objects | A raw JSON string ({"id":1}) isn’t an object until parsed. |
Type mismatch: expected object, got string |
The Set node stores values exactly as you provide them; downstream nodes validate the incoming data against their own schema and raise the mismatch error.
2. Debugging Workflow – Step‑by‑Step
If you encounter any n8n function node syntax error resolve them before continuing with the setup.
2.1 Identify the offending field
Open the Execution Log → click the red error badge on the Set node.
The log displays fieldName: <value> (type: X).
2.2 Inspect the source of the value
- Static literal – note its type (quotes → string, no quotes → number/boolean).
- Expression – hover the expression (
{{$json["price"]}}) to see the runtime type in the preview pane.
2.3 Check downstream expectations
Click the gear icon on the next node (e.g., HTTP Request, Spreadsheet) → Field Types.
Record the required type for the field that receives the Set node’s output.
2.4 Apply explicit conversion
Edit the field in the Set node → Add expression → use one of the snippets below.
Converting a string to a number
{{ Number($json["price"]) }}
Converting a number to a string
{{ String($json["price"]) }}
Parsing a JSON string into an object
{{ JSON.parse($json["payload"]) }}
Serialising an array for APIs that expect a string
{{ JSON.stringify($json["items"]) }}
2.5 Re‑run the workflow
Verify that the error disappears and that downstream nodes receive the expected type.
3. Common Scenarios & Targeted Code
3.1 API returns numeric values as strings
Problem: "total": "42.5" (string) → downstream calculation expects a number.
Set node configuration (field totalNumber):
| Field | Expression |
|---|---|
| totalNumber |
{{ Number($json["total"]) }}
|
3.2 Webhook sends a JSON string instead of an object
Problem: payload: "{\"id\":10,\"status\":\"ok\"}" → Airtable expects an object.
Set node configuration (field payloadObj):
| Field | Expression |
|---|---|
| payloadObj |
{{ JSON.parse($json["payload"]) }}
|
3.3 CSV import yields boolean values as strings
Problem: "active": "true" (string) → API rejects string booleans.
Set node configuration (field active):
| Field | Expression |
|---|---|
| active |
{{ $json["active"] === "true" }}
|
4. Production‑Grade Checklist
If you encounter any n8n function node reference error resolve them before continuing.
| Checklist Item | Why it matters | How to verify |
|---|---|---|
| Explicit type conversion | Prevents hidden runtime errors. | Review all Set fields that use expressions; ensure they call Number(), String(), JSON.parse(), etc. |
| Consistent schema across branches | Parallel paths must output the same types. | Run a Test Run on each branch and compare the JSON output (use the **Data Preview** pane). |
Avoid null/undefined when a value is required |
Many APIs reject missing fields. | Add a fallback: {{ $json["value"] ?? "" }} or {{ $json["value"] ?? 0 }}. |
| Validate after conversion | Guarantees the conversion succeeded (e.g., Number("abc") → NaN). |
Add a Function node after Set: if (isNaN(item.amount)) throw new Error("Invalid number"); |
| Document expected types in node descriptions | Helps future maintainers. | Use the **Notes** field in the Set node to write “totalNumber – number”. |
5. EEFA (Error, Edge, Fix, Advice) Nuggets
| Error | Edge case | Fix | Advice |
|---|---|---|---|
| Type mismatch: expected object, got string | Webhook payload is double‑encoded JSON. | {{ JSON.parse(JSON.parse($json[“payload”])) }} | Request raw JSON from the provider or clean it once in a dedicated Function node. |
| Type mismatch: expected number, got NaN | Number(“12abc”) returns NaN. | {{ Number($json[“price”].replace(/[^\d.-]/g, “”)) }} | Sanitize numeric strings at the source (e.g., in HTTP Request headers or query parameters). |
| Type mismatch: expected array, got object | API returns a single object instead of an array for a list endpoint. | {{ Array.isArray($json[“data”]) ? $json[“data”] : [$json[“data”]] }} | Normalise the shape early (first Set node) so downstream nodes can always assume an array. |
Conclusion
A “Type mismatch” in an n8n Set node is always a data‑type contract violation between the Set node and its downstream consumer. By identifying the offending field, inspecting the source value, and applying explicit JavaScript conversions, you restore type integrity and keep the workflow stable in production. Use the checklist to embed validation and documentation early, and you’ll eliminate these errors before they surface. The result is a reliable, maintainable automation that behaves predictably across all runtime environments.
