Issues Connecting Retool to My App - API Requests Not Working

[zeel.metha]

Hello Retool Community,

I'm experiencing issues connecting Retool with my application. Despite meeting all the necessary conditions, Retool is unable to send API requests to my app. Here are the details:

1. Custom Authentication: I have implemented custom authentication in Retool, using my app’s login API with the correct credentials. I verified the API works correctly using Postman.
2. CORS: Our backend is configured to allow calls from any server, so a CORS issue should not be the cause.
3. Simple API Requests: I also tested our metrics API, which doesn’t require any authentication. It’s a straightforward GET request that returns some data. Despite this simplicity, I'm encountering the same issue.

Here are all the images of the procedure i followed:

Hitting Auth :

response:

custom auth:

defining result in a variable:

In summary, even basic API calls that work perfectly in Postman fail when attempted through Retool.

Has anyone faced similar issues or can offer any insights into what might be going wrong?

Thanks in advance for your help!

[zeel.metha]

login api used in custom auth in working condition with same credentials:

basic api get call which does not need any auth token:

[MiguelOrtiz]

Hey @zeel.metha,

Try removing Bearer from your variable value and add that to the header key of your api call once user is auhenticated

[zeel.metha]

Hey @MiguelOrtiz ,

I have used a custom auth here which uses login api of my app and returns a token. But while authenticating my resource i can not see any logs of any api reaching my backend servers.

[Tess]

Hey @zeel.metha,

I agree with Miguel, I'd remove Bearer from the token:

The token will only be used if you reference it back in the headers. Have you done something like this already:

[zeel.metha]

Hey @Tess,

I have tried removing the Bearer from the token. But the main issue is not here. The custom Auth that i have made fails and does not return anything.

As you can see here the Test auth workflow fails itself.
Api -> https://app-dev.leadzen.ai/api/auth/jwt/login
body -> form data with fields username and password.
but it returns status code 400

I have tested the same api on postman too with same body inputs which returns a token.

with no headers.

[Tess]

Hi @zeel.metha,

The header would not be referenced in the custom auth. It would be added to the top where we have the base url.

As a test, if you hardcode the username & password instead of referencing {{form1...}}, does the test auth work?

Is the define a variable step directly after the api request? It might help to see a screenshot of the full page

[zeel.metha]

Hi @Tess,
Here is the screenshot of hardcoded username and password:

The auth test is still failing.
And, yes variable is directly after the api request.

[Tess]

Thanks! I'd change the variable to only {{http2.body.access_token}}

It doesn't look like the bearer token is being used in the request, which may explain the 400 error. Can you try adding the token to the request headers? That is where you can put Bearer USER_TOKEN

[zeel.metha]

Thanks @Tess,
I have removed the bearer keyword and added it to the headers as you told but the Test Auth workflow is still failing.

It is still not working.

[zeel.metha]

This is the whole auth workflow and when i click on test auth workflow it returns Test auth workflow failed.

[Tess]

Very strange. Have you checked all of the headers on the postman request? It looks like there are 11. We may need to specify a content type or accept header.

We can try to compare the exact postman request with the Retool request. On the Retool side, you can expand the error to see the specific request that is sent

I'd also be curious if this api request is working in a Retool query for comparison

[zeel.metha]

Well, here are the 11 headers on the postman request:

I don't think they are the reason for api failing again and again.
And this problem has occurred only a month ago. Before that this same Custom auth workflow was working perfectly.

[Tess]

Thanks, that is helpful. I didn't see any known bugs/regressions that would be related to this, but let me check again with that rough timeline & I'll follow up here