Credentials can now be created in team projects via public API

The public REST API for creating credentials now lets you specify which project owns the credential, instead of automatically filing it in the user's personal project.
Automated workflows that use n8n's public API previously hit a wall: credentials had to land in the user's personal project, with no way to create them in team projects. This blocked CI/CD pipelines and other automation that needed fine-grained access control across a team's infrastructure.
The POST /api/v1/credentials endpoint now accepts an optional projectId field. When omitted, the behavior stays the same — credentials go to the user's personal project. When provided, the credential is created in that project, assuming the user has access to it.
Error handling was also tightened. When a project doesn't exist, the API now returns 404 instead of 400. When a user lacks permission to a project, 403 is returned instead of silently failing.
Under the hood, the public API now delegates credential creation to the same CredentialsService used by the internal API, reducing duplication and ensuring consistent behavior across both surfaces.
In the n8n CLI package's public API handlers, credential creation flows through the service layer for the first time.
View Original GitHub DescriptionFact Check
Summary
Adds support for specifying a projectId when creating credentials via the public REST API (POST /api/v1/credentials). Without this, credentials always land in the user's personal project, blocking automated workflows that need to create credentials in team projects.
Changes:
- Extends
POST /api/v1/credentialsrequest body to accept an optionalprojectIdfield - Rafctoring: delegates to CredentialService to unify the behaviour with internal API
- Returns
404when the specified project does not exist, and403when the user lacks access to it (previously both returned400)
https://www.loom.com/share/a835a8f3cf644c05b8fdf8b7d5ba957e
Related Linear tickets, Github issues, and Community forum posts
Closes LIGO-418
Review / Merge checklist
- I have seen this code, I have run this code, and I take responsibility for this code.
- PR title and summary are descriptive. (conventions) <!-- **Remember, the title automatically goes into the changelog. Use `(no-changelog)` otherwise.** -->
- Docs updated or follow-up ticket created.
- Tests included. <!-- A bug is not considered fixed, unless a test is added to prevent it from happening again. A feature is not complete without tests. -->
- PR Labeled with
Backport to Beta,Backport to Stable, orBackport to v1(if the PR is an urgent fix that needs to be backported)