How to handle Settings in N8N API Update Workflow

Hello!

Using the N8N API node, “Create” or “Update” does not support the settings “callerPolicy”, “executionOrder” and many more.

image

This means anytime we use this node, the “executionOrder” is set to v0, which in practice make this not unusable.

Documentation: API reference | n8n Docs

Could you please tell me how I could solve this? Maybe by using a custome API call?

Hey @Lesterpaintstheworld,

Good spot it looks like we missed that, I think the most important one might be the execution order for now.

3 Likes

Yeah this would be great. For now it makes the APIs unusable imo as they default to legacy execution order.

Hey @Jon , about this issue do you have any update about this request? This is on your roadmap in the short releases?

Thanks for now.

Hey @rodrigoscdc,

Right now it is on my list of things to sort out but it could be that one of the teams will pick it up for their Q1 roadmap plans. I will do some searching and see if I can find anything.

1 Like

+1

DON’T DO THIS:

DO THIS:
The only way on n8n 1.29.1 for updating correctly, it’s to update the settings json object with an UPDATE query in SQL for properly write the settings.

                              Table "public.workflow_entity"
    Column    |            Type             | Collation | Nullable |       Default        
--------------+-----------------------------+-----------+----------+----------------------
 name         | character varying(128)      |           | not null | 
 active       | boolean                     |           | not null | 
 nodes        | json                        |           | not null | 
 connections  | json                        |           | not null | 
 createdAt    | timestamp(3) with time zone |           | not null | CURRENT_TIMESTAMP(3)
 updatedAt    | timestamp(3) with time zone |           | not null | CURRENT_TIMESTAMP(3)
 settings     | json                        |           |          | 
 staticData   | json                        |           |          | 
 pinData      | json                        |           |          | 
 versionId    | character(36)               |           |          | 
 triggerCount | integer                     |           | not null | 0
 id           | character varying(36)       |           | not null | 
 meta         | json                        |           |          | 
Indexes:
    "workflow_entity_pkey" PRIMARY KEY, btree (id)
    "IDX_workflow_entity_name" btree (name)
    "pk_workflow_entity_id" UNIQUE, btree (id)
Referenced by:
    TABLE "workflow_history" CONSTRAINT "FK_1e31657f5fe46816c34be7c1b4b" FOREIGN KEY ("workflowId") REFERENCES workflow_entity(id) ON DELETE CASCADE
    TABLE "execution_entity" CONSTRAINT "fk_execution_entity_workflow_id" FOREIGN KEY ("workflowId") REFERENCES workflow_entity(id) ON DELETE CASCADE
    TABLE "shared_workflow" CONSTRAINT "fk_shared_workflow_workflow_id" FOREIGN KEY ("workflowId") REFERENCES workflow_entity(id) ON DELETE CASCADE
    TABLE "webhook_entity" CONSTRAINT "fk_webhook_entity_workflow_id" FOREIGN KEY ("workflowId") REFERENCES workflow_entity(id) ON DELETE CASCADE
    TABLE "workflow_statistics" CONSTRAINT "fk_workflow_statistics_workflow_id" FOREIGN KEY ("workflowId") REFERENCES workflow_entity(id) ON DELETE CASCADE
    TABLE "workflows_tags" CONSTRAINT "fk_workflows_tags_workflow_id" FOREIGN KEY ("workflowId") REFERENCES workflow_entity(id) ON DELETE CASCADE

db5610b774fd4d4939ba930d452a0dceea=> SELECT * FROM workflow_entity LIMIT 1;
db5610b774fd4d4939ba930d452a0dceea=> SELECT settings FROM workflow_entity LIMIT 1;
                                                            settings                                                            
--------------------------------------------------------------------------------------------------------------------------------
 {"saveManualExecutions":true,"callerPolicy":"workflowsFromSameOwner","executionOrder":"v1","errorWorkflow":"ROU6HhpOfawIdKe7"}
(1 row)

Wow. It sounds like the entire “Update Workflow” API endpoint is broken at this point. There’s no way to just manipulate settings of other workflows through it – is that correct?

@dkindlund you can update workflows but there are some settings that are not supported at the moment.

You can find the options that can be set in the API documentation

Check out what I’m trying to do in this scenario, @Jon:

Can we add this feature ?

I want to set callerPolicy : any for my workflows. I cannot access the Postgres DB because i’m on the Cloud “Pro” plan…