Gitpulse
Merged
Size
M
Change Breakdown
Feature70%
Bug Fix20%
Refactor10%
#27884feat(core): Support projectId when creating workflow via public API

Workflows can now be created in specific projects via API

Workflows can now be created in specific projects via API
SA
sandra0503
·Apr 7, 2026

The public API now accepts a projectId parameter, letting callers create workflows directly in the right project instead of always defaulting to personal space.

The n8n public API's workflow creation endpoint can now target specific projects. Previously, POST /workflows always created workflows in the calling user's personal project — no exceptions. Teams managing multiple projects had to work around this limitation, writing additional code to move workflows after creation or accepting the constraint entirely.

With this change, callers can include an optional projectId in the request body. The API validates project existence and user permissions before proceeding, returning 404 if the project doesn't exist or 403 if the user lacks access. When projectId is omitted, behavior remains unchanged — workflows still land in the user's personal project.

The fix also corrects the order of authorization checks. Previously, credential validation ran before project authorization, meaning callers received unhelpful error responses when the target project was inaccessible. Now project permissions are checked first, so the API returns the semantically correct HTTP status.

These changes live in the CLI package's public API handlers, with the actual workflow creation delegated to the existing WorkflowCreationService rather than duplicated inline.

View Original GitHub Description

Summary

The public API POST /workflows endpoint now accepts an optional projectId in the payload, allowing callers to create workflows directly in a specific project instead of always defaulting to the user's personal project.

Changes:

  • Added optional projectId to request body of POST /workflows
  • Delegates to WorkflowCreationService
  • Fix order in WorkflowCreationService: project authorization now runs before credential validation so callers receive the correct HTTP status when the target project is missing or inaccessible
  • Returns 404 if the project doesn't exist, 403 if the user lacks access
  • Falls back to the user's personal project when projectId is omitted

https://www.loom.com/share/0a0a796d89b446f6a0e4577531e6b7b6

How to test:

# Create workflow in a specific project
curl -X POST 'http://localhost:5678/api/v1/workflows?projectId=<PROJECT_ID>' \
  -H 'X-N8N-API-KEY: <API_KEY>' \
  -H 'Content-Type: application/json' \
  -d '{"name": "test", "nodes": [...], "connections": {}, "settings": {"executionOrder": "v1"}}'

# Without projectId — still creates in personal project
curl -X POST 'http://localhost:5678/api/v1/workflows' ...

Related Linear tickets, Github issues, and Community forum posts

https://linear.app/n8n/issue/LIGO-430

Review / Merge checklist

  • PR title and summary are descriptive. (conventions)
  • Docs updated or follow-up ticket created.
  • Tests included.
  • PR Labeled with release/backport (if the PR is an urgent fix that needs to be backported)
© 2026 · via Gitpulse