Accessing the OpenWebUI API

[joseph]

Works for me . What failed for you? I used a API Key (NOTE: this is different from JWT token, I don't know how to use a JWT token)

[JOduMonT]

@joseph what failed me

and thanks for testing on your side

• I fail at understanding properly API

so;
how did you generate the API key ?
under JWT Token?

and you connected only with the API key; did'nt use the JWT ?

[joseph]

There was a button to generate the API key. It was not already created .

After I created it, I just ran curl -H "Authorization: Bearer YOUR_API_KEY" https://openwebui.domain.com/api/models and it returned me some array.

[JOduMonT]

thanks

so it only works for me in n8n
if I use the external domain (https://openwebui.domain.com/api/models)
it does'nt work with App ID: http://e704da83-fe32-3032-133f-01ba96ab147b/api/models

[nebulon]

Do you have any error codes or so to share? Also just to make sure, if you run host e704da83-fe32-3032-133f-01ba96ab147b from a webterminal into n8n, does it resolve correctly to the openwebui container?

If yes, it is also possible that openweb ui validates the hostname which in this case wouldn't be known by it. So either way using the actual domain of the app will be the correct way, also https will only work there.

[robi]

@nebulon Is it the firewall and needs the IP to go on the whitelist?

[robi]

This post is deleted!

[nebulon]

@JOduMonT did you manage to get this solved by using the domain of the app, which would be the correct thing to do.

[JOduMonT]

@nebulon no

I have another case with a similar issue

in n8n I want to access searxng as a tool to my AI.
in the n8n container I'm able to do query via curl to my searxng via the http://containerID:8888
but inside n8n it say the service is down (refuse to connect)

curiously if I use https://searxng.domain.tld it work

As Robi mentionned; does cloudron implemented a firewall internally ?

or maybe it is more a DNS issue since journalctl -u docker return me a bunch of DNS error:

Mar 01 05:22:50 cloudron dockerd[795]: time="2025-03-01T05:22:50.303058317Z" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:127.0.0.1:56347" dns-server="udp:127.0.0.53:53" error="read udp 127.0.0.1:563>
Mar 01 05:23:23 cloudron dockerd[795]: time="2025-03-01T05:23:23.818259449Z" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:127.0.0.1:44377" dns-server="udp:127.0.0.53:53" error="read udp 127.0.0.1:443>
Mar 01 05:23:42 cloudron dockerd[795]: time="2025-03-01T05:23:42.069168113Z" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:127.0.0.1:53714" dns-server="udp:127.0.0.53:53" error="read udp 127.0.0.1:537>
Mar 01 05:23:59 cloudron dockerd[795]: time="2025-03-01T05:23:59.865583114Z" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:127.0.0.1:39963" dns-server="udp:127.0.0.53:53" error="read udp 127.0.0.1:399>
Mar 01 05:24:48 cloudron dockerd[795]: time="2025-03-01T05:24:48.532971799Z" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:127.0.0.1:39152" dns-server="udp:127.0.0.53:53" error="read udp 127.0.0.1:391>
Mar 01 05:25:03 cloudron dockerd[795]: time="2025-03-01T05:25:03.514238819Z" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:127.0.0.1:58625" dns-server="udp:127.0.0.53:53" error="read udp 127.0.0.1:586>
Mar 01 05:26:24 cloudron dockerd[795]: time="2025-03-01T05:26:24.759362556Z" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:127.0.0.1:40413" dns-server="udp:127.0.0.53:53" error="read udp 127.0.0.1:404>
Mar 01 05:26:39 cloudron dockerd[795]: time="2025-03-01T05:26:39.816576683Z" level=error msg="[resolver] failed to query external DNS server" client-addr="udp:127.0.0.1:55967" dns-server="udp:127.0.0.53:53" error="read udp 127.0.0.1:559>

[nebulon]

So querying via container ID is not really something Cloudron works with. This is just something docker does, but that does not mean that ports are exposed on those interfaces. Also since container ids may change over time, the correct way to do this is to use the normal domain of an app.