n8n - 💡(How to fix) Fix Public API: all /api/v1/* data endpoints return 500 "Internal server error" with no stack trace (n8n 2.17.4, Postgres)

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

Public API returns 500 "Internal server error" on all data endpoints (no stack trace surfaced)

All n8n Public REST API data endpoints (/api/v1/workflows, /api/v1/credentials, /api/v1/users, /api/v1/executions, /api/v1/projects, /api/v1/audit) return HTTP 500 {"message":"Internal server error"} immediately.

  • GET /rest/login → 400 (validation error, as expected)

→ HTTP/2 500 {"message":"Internal server error"}

  • HTTP 500 with body {"message":"Internal server error"}
  • With N8N_LOG_LEVEL=debug, the request does not produce any log entry — no stack trace, no error log, no audit event. The error handler appears to swallow the exception silently.
  • ❌ Enabling N8N_LOG_LEVEL=debug does not surface any log line for the failing request, suggesting the error is caught and silently returned as 500 before reaching the standard middleware logger. When the Public API route handler throws, the response body should not be reduced to {"message":"Internal server error"} and the exception silently dropped from the logger. At minimum, the original error message + stack should be written to the structured log at error level, even in production. As it stands, the operator has no signal to debug.

Root Cause

Suggested improvement (regardless of root cause)

Fix Action

Fix / Workaround

Workaround in use

CLI export still works, so I am using n8n export:workflow --all --output=/tmp/all-workflows.json for any bulk read operation that would normally hit the public API. This is fine for read-side automation but blocks anything that needs POST/PATCH against /api/v1/*.

Code Example

# Any of the following — all return HTTP 500 with the same generic body
curl -i "$N8N_HOST/api/v1/workflows?limit=1" -H "X-N8N-API-KEY: $KEY"
curl -i "$N8N_HOST/api/v1/credentials"        -H "X-N8N-API-KEY: $KEY"
curl -i "$N8N_HOST/api/v1/users"               -H "X-N8N-API-KEY: $KEY"
curl -i "$N8N_HOST/api/v1/executions?limit=1"  -H "X-N8N-API-KEY: $KEY"
curl -i "$N8N_HOST/api/v1/projects"            -H "X-N8N-API-KEY: $KEY"

# Even without an API key:
curl -i "$N8N_HOST/api/v1/workflows?limit=1"
# → HTTP/2 500 {"message":"Internal server error"}

---

N8N_PUBLIC_API_ENABLED=true
N8N_PUBLIC_API_DISABLED=false
N8N_API_KEY_ENABLED=true
N8N_PROXY_HOPS=1
N8N_RUNNERS_ENABLED=true
N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE=true
N8N_RESTRICT_FILE_ACCESS_TO=/home/node/.n8n/tmp
NODE_FUNCTION_ALLOW_EXTERNAL=xlsx
DB_TYPE=postgresdb
NODE_ENV=production
GENERIC_TIMEZONE=Asia/Taipei
RAW_BUFFERClick to expand / collapse

Public API returns 500 "Internal server error" on all data endpoints (no stack trace surfaced)

Bug description

All n8n Public REST API data endpoints (/api/v1/workflows, /api/v1/credentials, /api/v1/users, /api/v1/executions, /api/v1/projects, /api/v1/audit) return HTTP 500 {"message":"Internal server error"} immediately.

The failure happens regardless of whether a valid X-N8N-API-KEY / Authorization: Bearer header is supplied, or no auth header at all — so it is not an auth/permission issue. The route handler appears to throw before (or independently of) authentication.

Static / meta endpoints under /api/v1 still work:

  • GET /api/v1/docs → 200 (Swagger UI HTML)
  • GET /api/v1/openapi.yml → 200 (spec, version: 1.1.0)
  • GET /healthz → 200
  • GET /rest/login → 400 (validation error, as expected)

The n8n core itself is fully healthy:

  • 1109 workflows activated successfully at boot, cron + webhook executions running normally
  • n8n export:workflow --all works
  • Editor UI works
  • DB connection healthy, last 5 migrations applied (newest: CreateTrustedKeyTables1776000000000)
  • workflow_entity contains 1110 rows; schema columns match expected layout (name, active, nodes, connections, meta, parentFolderId, isArchived, versionCounter, description, activeVersionId, …)

To reproduce

# Any of the following — all return HTTP 500 with the same generic body
curl -i "$N8N_HOST/api/v1/workflows?limit=1" -H "X-N8N-API-KEY: $KEY"
curl -i "$N8N_HOST/api/v1/credentials"        -H "X-N8N-API-KEY: $KEY"
curl -i "$N8N_HOST/api/v1/users"               -H "X-N8N-API-KEY: $KEY"
curl -i "$N8N_HOST/api/v1/executions?limit=1"  -H "X-N8N-API-KEY: $KEY"
curl -i "$N8N_HOST/api/v1/projects"            -H "X-N8N-API-KEY: $KEY"

# Even without an API key:
curl -i "$N8N_HOST/api/v1/workflows?limit=1"
# → HTTP/2 500 {"message":"Internal server error"}

Calling from inside the container against http://localhost:5678 produces the same 500, so it is not a reverse-proxy issue.

Expected behavior

GET /api/v1/workflows should return { data: [...], nextCursor: ... } per the OpenAPI spec, or a proper 401/403 if auth is missing/invalid.

Actual behavior

  • HTTP 500 with body {"message":"Internal server error"}
  • Response headers indicate the body originates from n8n (content-length: 35, etag present), not from a reverse proxy
  • With N8N_LOG_LEVEL=debug, the request does not produce any log entry — no stack trace, no error log, no audit event. The error handler appears to swallow the exception silently.

n8n setup information

  • n8n version: 2.17.4
  • Public API spec version (from /api/v1/openapi.yml): 1.1.0
  • Database: PostgreSQL 17.9 (Debian build)
  • Last applied migrations (newest first):
    1. CreateTrustedKeyTables1776000000000
    2. ChangeWorkflowPublishHistoryVersionIdToSetNull1775740765000
    3. CreateTokenExchangeJtiTable1775116241000
    4. CreateInstanceAiTables1775000000000
    5. CreateInstanceVersionHistoryTable1774854660000
  • n8n EXECUTIONS_PROCESS: default (main, single-instance)
  • Running n8n via: Docker (Zeabur prebuilt template)
  • Operating system: Linux (Alpine-based n8n image), kernel x86_64
  • Node.js version inside container: v24.14.1
  • Reverse proxy: Zeabur edge (terminates TLS, adds X-Forwarded-For)

Relevant environment variables

N8N_PUBLIC_API_ENABLED=true
N8N_PUBLIC_API_DISABLED=false
N8N_API_KEY_ENABLED=true
N8N_PROXY_HOPS=1
N8N_RUNNERS_ENABLED=true
N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE=true
N8N_RESTRICT_FILE_ACCESS_TO=/home/node/.n8n/tmp
NODE_FUNCTION_ALLOW_EXTERNAL=xlsx
DB_TYPE=postgresdb
NODE_ENV=production
GENERIC_TIMEZONE=Asia/Taipei

API key was freshly generated from Settings → API in the editor UI (JWT, iss: n8n, aud: public-api, valid iat).

What I have already verified / ruled out

  • N8N_PROXY_HOPS=1 is set — the previous ERR_ERL_UNEXPECTED_X_FORWARDED_FOR warnings stopped after restart; this is not the cause of the 500.
  • ✅ Issue reproduces from inside the container against http://localhost:5678, so reverse proxy / TLS / forwarded headers are not involved.
  • ✅ Issue reproduces with no auth header as well as with a freshly-generated valid API key in both X-N8N-API-KEY and Authorization: Bearer … forms.
  • ✅ DB is reachable and healthy from the same node process (pg client query succeeds; workflow_entity has 1110 rows).
  • ✅ The Editor, webhook engine, CLI (n8n export:workflow --all), cron triggers, and execution save all work without errors.
  • ✅ Static public-API assets respond: /api/v1/docs, /api/v1/openapi.yml.
  • ❌ Enabling N8N_LOG_LEVEL=debug does not surface any log line for the failing request, suggesting the error is caught and silently returned as 500 before reaching the standard middleware logger.

Suggested improvement (regardless of root cause)

When the Public API route handler throws, the response body should not be reduced to {"message":"Internal server error"} and the exception silently dropped from the logger. At minimum, the original error message + stack should be written to the structured log at error level, even in production. As it stands, the operator has no signal to debug.

Workaround in use

CLI export still works, so I am using n8n export:workflow --all --output=/tmp/all-workflows.json for any bulk read operation that would normally hit the public API. This is fine for read-side automation but blocks anything that needs POST/PATCH against /api/v1/*.


Happy to attach a full debug log, the full env dump, or run any additional diagnostic the team suggests.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

GET /api/v1/workflows should return { data: [...], nextCursor: ... } per the OpenAPI spec, or a proper 401/403 if auth is missing/invalid.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING