I am implementing the github backup workflow and the api call to receive a list of all workflows returns the whole webpage, am I using the wrong link?
Guess I’m just simple… it returns the signup page because my request is not authorized… oops
https://my-cloud-url/rest/workflows
Hi @Maarten_Bruyninx, can you confirm which workflow exactly you mean? In general, the undocumented API used by the UI would be available under localhost:5678 from inside the cloud instance and requires a token. So fetching workflows could work like so (where the basic auth credentials used by the first node are your cloud username and password):
Alternatively you might want to consider using the official REST API instead of the undocumented UI API (which can change without notice). The official API is documented here: The n8n public API - n8n Documentation
You might want to consider upgrading to [email protected] first though as this version includes a crucial fix for the REST API.
Is it not possible to just auth the fetch request with a basic auth (the login details of N8N cloud)
That’s what my example workflows does, but it requires two separate requests I am afraid. The official REST API would only require a single API request (using a token) though and should really be the preferred option.
Can you expand the error details? I tested the example workflow I have posted above on n8n cloud just now and it was working fine for me, returning my workflows as expected:
Is there a chance your username or password fields have a trailing or leading whitespace causing the authentication to fail?
I didnt change the auth url 
but the issue remains
Hi @Maarten_Bruyninx, please don’t share a screenshot of your cookie. It should be kept just as secret as your username and password as it can be used to authenticate with Google cloud. You’d also need to update the URL of your second HTTP Request node to http://localhost:5678/rest/workflows for this to work.
Even when we are using the cloud? We are not local hosting N8N
Yes, even on n8n cloud. This is because the instance essentially talks to itself here and does this via localhost:5678. So requests sent to localhost aren’t routed via the cloud UI but directly to the instance which is what makes this work.
Alright, I got the list now… thanks 
seems a bit counter logic to me 
and thanks for correcting my ignorance with the cookie
No worries, it really is confusing 
Luckily, with the official REST API rolled out this won’t be necessary very often going forward.
I will check it out, currently trying to learn as much as I can in N8N 
, I will check out the other option
