The error {"message":"DELETE method not allowed"} indicates that while the server recognized your URL, it rejected the DELETE request because the specific endpoint doesn’t support that HTTP method. The most common cause is that your credentialID isn’t being correctly substituted—if you’re sending the literal string {credentialID} instead of the actual credential ID, n8n treats the request as a call to the credentials collection (/api/v1/credentials) rather than a specific credential (/api/v1/credentials/123), and the DELETE method isn’t available on the collection endpoint.
You likely need to verify that your actual credential UUID or numeric ID is present in the URL. If direct calls to the IP and port work but fail behind a proxy, your reverse proxy configuration (like Nginx) might be blocking DELETE requests. Ensure you’re using the correct authentication header (X-N8N-API-KEY), and try bypassing any proxy layer to test if the issue is with the method request itself or your proxy configuration.
The 405 comes from the public API spec shipped with 2.39.2, not from your ID. In that spec DELETE is declared under /credentials/{id}, while the same URL is also declared as /credentials/{credentialId} with GET only, and the request validator n8n uses answers DELETE with its own 405 “DELETE method not allowed”.
I ran the published specs through the validator version 2.39.2 depends on (express-openapi-validator 5.5.3): 2.39.2 and 2.39.8 return the same 405 and message you got, both for a real-looking ID and for a literal {credentialID}, and from 2.39.9 the two paths are merged and DELETE gets through. That was the validator with each version’s spec, not a full n8n instance, so I’d back up Postgres, move the image to 2.39.10 (the newest 2.39.x) and try the same call.
DELETE /api/v1/credentials/{id} is supported in n8n 2.39.2. Using an incorrect ID doesn’t turn that URL into a request to the /credentials collection endpoint.
Could you share the actual request as cURL with secrets removed, plus the HTTP status and response headers? Please include the URL after any variables have been resolved. That will help check the exact path being called and where the response comes from.
405 means the request never reached the auth check: n8n answers “method not allowed” when the route exists but does not register that verb, so a working X-N8N-API-KEY is expected here and not the problem.
Two differentials settle it:
GET the same URL with the same key. If GET returns the credential, routing is fine and your build simply does not expose DELETE on /api/v1/credentials/{id} (older versions only shipped GET/POST/PATCH) - then check the version under Settings > About (or n8n --version) and delete via the UI until you upgrade.
If GET also returns 405, something in front of :5678 (reverse proxy, API gateway, tunnel) is rejecting the verb, and no change inside n8n will help.
On a build that predates the endpoint, the internal REST route DELETE /rest/credentials/{id} works with a browser session cookie, but it is not the public API and your API key will not authenticate it.
Try the same DELETE with curl on the docker host against localhost:5678 with your X-N8N-API-KEY header, that skips anything sitting in front of n8n. If it works there, a proxy or firewall is probably blocking DELETE. Is there nginx or some gateway between you and the container?
We have taken a look at this and it looks like it might be fixed in a recent release, Please update and see if you are still running into the same problem.
We have taken a look at this and it looks like it might be fixed in a recent release, Please update and see if you are still running into the same problem.