The connection to Ollama Cloud worked fine but didn't provide any results from the Model list

Hi all!

I am quite new to n8n, and I’m trying to set up a connection to Ollama Cloud. I have copied my api key from Sign in and made a new host credential connection in n8n, and changing the base url to https://ollama.com. The connection tested successfully but when trying to use it the list of models isn’t loading, and it returns with the “No results” message. Have anyone experience similar issues before, since it appears that the connection authenticates but no models are to be found?

Thanks in advance,

@mitidi the base url should be https://ollama.com/api not just https://ollama.com, that’s why the connection passes but the model list comes back empty — the auth endpoint works at the root but the models endpoint needs the /api path. update that and the dropdown should populate.

Not really, this works for me

The key thing is whether Ollama chat model or OpenAI chat model is being used.

Ollama chat model can use https://ollama.com

OpenAI chat model will use https://ollama.com/v1

Hi @mitidi

I’d usually bypass the model dropdown entirely and call the Ollama Cloud API directly with an HTTP Request node. A good first check is to call GET https://ollama.com/api/tags with the same API key and confirm that the models are visible at the API level. If that works, you can continue with direct API calls instead of depending on the built-in model list. That’s a useful way to tell whether the issue is with the node’s model picker/UI rather than authentication itself.

The three replies above each solve a different failure mode — which one applies depends on what you actually wired up. Quick triage before you change anything:

1. **Confirm the node type first.** In your workflow, is the node labelled `Ollama Chat Model` or `OpenAI Chat Model (with base URL override)`? The dropdown population code path is different for each. kjooleng is right that Ollama-native node wants `https://ollama.com` and OpenAI-compat node wants `https://ollama.com/v1` — the `/api` suffix achamm mentioned is only relevant if you’re hand-calling the legacy Ollama REST surface via HTTP Request node.

2. **Verify the key is actually reaching the list endpoint.** `curl -H “Authorization: Bearer ” https://ollama.com/api/tags` from the same machine n8n runs on. If that returns models but the n8n dropdown is still empty, it’s not auth — it’s that n8n’s credential-test endpoint and model-list endpoint are hitting different paths, and your base URL only satisfies one of them.

3. **Check if your Ollama Cloud account is org-scoped.** Some cloud accounts gate model visibility behind an org ID header that n8n’s built-in credential form doesn’t expose.

Broader note from having hit this shape across Ollama / OpenRouter / Anthropic / Gemini: the root cause is almost always that each vendor’s base-URL and header conventions are slightly off from what n8n’s credential form assumes, and you end up rebuilding the same injection logic per provider. Some of us have been working on an open-source credential proxy that sits in front of these providers and normalizes the quirks — n8n just points at the proxy. Happy to DM if that angle would help once you’ve isolated which of the three failure modes above is yours.