N8N API - Unable to Set Credential

I’m running into a pretty basic problem that I feel like I should be able to sort out.

Environment is self hosted queue mode on docker. This is running in a browser accessible environment (ie. not on a local/desktop machine).

I’m trying to set the credential for the n8n API to use in workflows. I generated the API key and plugged it in. I set the Base URL like https://:5678/api/v1 , but it says it can’t connect with these settings.

I do not have an N8N_PATH variable set. I double-checked it wasn’t being specified by checking the variables with “set”, so I assume it should be “/”.

Anything obvious I can double-check here?

Hi @mbowler, I am not sure I understand the problem based on your description.

https://:5678/api/v1 seems like an invalid API URL. Are you deploying an SSL certificate directly via n8n rather than your load balancer or reverse proxy?

Assuming you have deployed n8n using a docker compose file like this:

version: '2'

    image: n8nio/n8n
      - 5678:5678
      - N8N_ENCRYPTION_KEY=wRg4yz33B7Z8QDL7QoK64nM
      - EXECUTIONS_MODE=queue
      - ./n8n:/home/node/.n8n
    image: redis:alpine
      - 6379:6379

n8n’s main instance would talk to itself via http://localhost:5678 and from other docker containers on the same network via http://n8n:5678 (where n8n is the name of the service).

This seems to work fine, at least using the n8n node (I haven’t tried other nodes yet as I am not 100% sure how exactly you’re calling the n8n API):

I didn’t check my post after I posted, so I understand the confusion. Apparently putting in “<“hostname”>” without quotes makes the text disappear. My url is is like this “https://“hostname”:5678/api/v1”, where hostname is the name of the host that is running the main instance. Once I get it working correctly, I may switch this to global private IP of the main instance to keep traffic internal

While I am on docker, the setup (for now) is such that n8n(main), redis, and postgres are each in their own containers on one host while the workers are in containers on a separate host, so just referring to the host as “n8n” won’t work (for now).

I am indeed using the n8n node and at least now I know that the URL is correct so I can continue to troubleshoot.

UPDATE: I was able to get the connection to “test successfully” in credentials, but I had to use http://localhost, which I’m thinking will probably create an issue if the workflow is running on a worker. Using the host’s fqdn and global private IP for some reason did not work.

Just a quick update. While localhost:5678/api/v1 worked, since I’m in a queue environment, this wouldn’t work for any non-manual runs. It turns out since I had port forwarding on for 5678 from the host to the container, if I removed 5678 from the n8n credential base URL, everything works as intended when then using the hostname instead of localhost.


Hey @mbowler,

This is why that template we provide is important, we would have known you were on queue mode sooner :slightly_smiling_face:

Glad to hear you have it working though

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.