N8N Field Notes

This post is a running log. I'm building out a fair amount of n8n automation lately, and I keep bumping into small gaps between what the platform does and what's easy to find in the docs. Rather than write a new post every time, I'm going to keep adding entries here as I stumble across them. Newest entries at the top.

Renaming credentials via the REST API (2026-07-06)

n8n's public API reference documents GET /api/v1/credentials for listing credentials (no secret data included) along with credential creation and deletion. What's easy to miss is that n8n also ships a PATCH /api/v1/credentials/{id} endpoint that lets you update a credential's name — and, if you want, its underlying data — after the fact.

To be fair to n8n: this endpoint isn't secret. It's mentioned in the release notes for the version it shipped in, and credential:update shows up as a real scope on the API authentication page. It's just not surfaced anywhere near where you'd naturally look — the credentials list/create docs don't mention it, and it's not obvious in the interactive API reference either. So "undocumented" isn't quite right; "easy to miss" is more accurate, and that's exactly how I found it: by guessing.

The natural first guess is PUT /api/v1/credentials/{id}. That returns a 405 Method Not Allowed — n8n's team has said as much in a GitHub thread, noting they added the PATCH endpoint specifically so a PUT wasn't needed.

The fix:

curl -X PATCH https://your-n8n-host/api/v1/credentials/{id} \
  -H "X-N8N-API-KEY: $KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "new-name"}'

Confirmed working against a self-hosted n8n instance as of 2026-07-06.

A couple of things worth knowing before you script this against a pile of credentials:

• You still can't read secrets this way. GET /api/v1/credentials/{id} returns a 403. n8n never exposes credential secret data via the API, even to the credential's owner — renaming (or updating other fields) is genuinely the extent of what's editable through this endpoint from a read-back perspective.
• It's purely cosmetic when you're just touching the name. Workflows reference credentials internally by ID, not by name, so renaming a credential through this endpoint won't break any workflow that uses it, no matter how many places it's referenced.

That's genuinely useful if you're managing credentials at any scale. n8n auto-generates a name the moment a credential is created, and it's rarely one you'd choose — think SSH Private Key account, SSH Private Key account - 1, SSH Private Key account - 2, and so on. Knowing this endpoint exists means you can fix those names programmatically instead of clicking into each credential in the UI one at a time to see what host it's for.

More entries to come as I keep finding the edges of what n8n's docs do and don't cover.