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 “/”.
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:
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.