n8n - 💡(How to fix) Fix Editor auto-redirects to new empty workflow when opening any API-created or API-updated workflow [1 comments, 2 participants]

Describe the problem/error/question

Workflows created via the public REST API render correctly when fetched via GET /api/v1/workflows/{id} but trigger a UI canvas redirect to a brand-new empty workflow when opened in the editor. The URL briefly loads with the correct workflow ID, then auto-redirects to /workflow/{newRandomId}?new=true with an empty canvas. A toast notification appears at the bottom-right of the canvas but flashes too quickly to read.

This blocks API-driven workflow deployment entirely. Workflows are runnable at the execution layer (the engine sees
them and would fire them) but they are unreachable in the editor.

The bug also reproduces on a UI-created blank workflow that is later updated via API: create blank in UI → save → call PUT /api/v1/workflows/{id} (full update) with populated nodes → reopen URL → same redirect.

I confirmed via the API that the workflow data is intact after the redirect — nodes and connections are populated correctly. The render failure happens client-side in the editor.

What is the error message (if any)?

No error message visible to me. A toast notification appears at the bottom-right corner of the canvas during the
redirect but it disappears too fast to read (likely under 200ms). Browser address bar visibly changes from /workflow/{originalId} → /workflow/{newRandomId}?new=true within ~1 second of page load.

Please share your workflow/screenshots/recording

Cannot use the keyboard-shortcut copy/paste because the canvas auto-redirects before nodes appear. Sharing the workflow IDs in my account so the engineering team can inspect the database state directly:

Currently affected (Personal project, projectId gIU19TTqfI0USokY):

• PP36EZ90d7q3N4dg — WL_Dedup_Gate (9 nodes, populated via API after UI Save)
• i2eOCJJ07hmBdYp0 — WL_Ingest_Classify (20 nodes, populated via API after UI Save)

Earlier examples renamed for evidence (same bug, different reproducer path — created entirely via API):

• 6J4H7NBUEl2XT1HO — _BROKEN_WL_Dedup_Gate_old
• V1iqnkfJ7d7vKFII — _BROKEN_WL_Ingest_Classify_old

Known-good reference workflow for comparison (created in UI months ago, renders correctly):

• k7xzEmJUq2mZeieq — Lead Response - Approval Executor v2

Share the output returned by the last node

Not applicable — the bug is in the editor render path, not in execution. The workflows have not run yet because we
cannot activate them from the UI.

For diagnostic completeness, here is what GET /api/v1/workflows/{id} returns vs what would distinguish a working vs
broken workflow:

Field | Broken PP36EZ90d7q3N4dg | Working k7xzEmJUq2mZeieq
nodes.length : 9 | 23
connections : populated (8 edges) | populated (14 edges)
pinData : {} | not in structure response
activeVersionId : null | null (so this is not the cause) staticData : null | unknown meta : null | unknown
settings.executionOrder : "v1" | "v1"
Node id format : semantic strings | semantic strings (so format isn't cause)
projectId : gIU19TTqfI0USokY | gIU19TTqfI0USokY (same project)

Hypotheses I have ruled out with evidence:

• activeVersionId: null — known-good v2 workflows also have it null
• pinData: null — after UI Save and then API update, pinData is {} and is preserved through the update
• Semantic vs UUID node IDs — known-good v2 workflow uses semantic IDs too
• Project scope — both broken and working live in the same Personal project
• Validation — validate-workflow returns zero errors at profile=runtime
• Autofix — autofix-workflow with applyFixes=true applied a typeVersion bump but did not change the redirect behavior

Why this matters

We use the n8n REST API as part of an automated workflow deployment pipeline. This bug means production workflows we create or modify via API become UI-inaccessible. Reproducible 100% of the time on this account. Blocks our production rollout entirely. We have not been able to identify a workaround at the API layer.

Happy to provide browser console logs, a screen recording, or any other diagnostic data on request. The four workflow IDs above are still in the account if your engineering team wants to inspect the database state directly.