Best practice for PUT workflow using JSON from GET API

Describe the problem/error/question

I’m trying to update a workflow via the n8n API (PUT /workflows/{id}).
I first fetched the workflow JSON using the GET API, and I wanted to PUT it back as-is — but I got this error:

{"message":"request/body must NOT have additional properties"}

I checked the API reference and tried trimming the fields with jq like this:

jq '{name, nodes, connections, settings, staticData, shared}'

But it still didn’t work :sweat_smile:
So I’d like to know — what’s the best practice for updating a workflow using the JSON definition from the GET API?
Is there a recommended way to clean or reformat the JSON before sending it back?


What is the error message (if any)?

{"message":"request/body must NOT have additional properties"}


Please share your workflow

(Used a simple workflow for testing; basically just a webhook and a code node.)


Share the output returned by the last node

N/A


Information on your n8n setup

  • n8n version: 1.106.0

  • Database: default (SQLite)

  • n8n EXECUTIONS_PROCESS: own

  • Running n8n via: Docker

  • Operating system: Ubuntu 22.04

hello @daisuke_hashimoto

You should remove some properties from the settings section, as not all of them are supported in the POST/PUT operation.

Check the API doc for the proper fields:

API reference | n8n Docs

Hi again, thanks for the reply!

I checked the API reference and removed unsupported fields using jq like this:

jq '{name, nodes, connections, settings, staticData, shared}'

But the request still fails :sweat_smile:

So I’d like to ask:

What is the recommended practice for updating a workflow using the JSON returned from the GET /workflows/{id} API?
Is there a standard way to clean or reformat the JSON before sending it back in a PUT request?

Any guidance or examples would be really helpful. Thanks!

That’s only the root level; you should also check that each of the root keys doesn’t have the extra fields, like here for the settings key:

Thanks for the advice! I gave it a try, but unfortunately it still didn’t work on my side :sweat_smile:
It would be really helpful if n8n could log which specific fields are causing the issue, so I’m hoping this will be improved in the future.

For now, my maintenance flow will be something like this:
download JSON from the GUI → move it to another environment → Create Workflow → import JSON → rename it to match the original → re-configure the Error Workflow.
This seems to be the most reliable approach for my setup :+1:

For me, it works to build the body as follows:

1 Like

Thank you so much! This is very helpful. I’ll use your example as a reference. I’ll close the thread now.