Error 400 Status messages on external API calls

We are experiencing a higher incidence rate of failed calls to one of our third party API providers, Docusign, from Retool. An example message that we get follows this format:
{"status":400,"message":"request to**** failed, reason: unable to verify the first certificate", error":true,"source":"resource"}

This message only appears intermittently and after several subsequent attempts to invoke the API call again, succeeds. We make identical calls to the same endpoints through other platforms and are not able to recreate the issue unless we issue the request through Retool.

Are their any best practices or recommendations for dealing with this type of certificate issue from within the Retool environment? Anecdotally our users have indicated that this is experienced more frequently in late afternoon (East Coast Time zone) and has occurred more frequently over the past few weeks.

Any suggestions you might have would be very much appreciated, thanks so much!

1 Like


We observe the same behavior on our side.

Any update on this thread from Retool teams ?


@victor.zoov happy to look into any specific API's you are having issues reaching!

I'm having the same problem w/ the REST API from the USPTO. This was working a couple weeks ago, but for the past few days, the response is:

request to failed, reason: unable to verify the first certificate

I can put the URL in my browser and get a response; however, using Postman, I have the same issue. Through postman, I'm able to turn off SSL validation and the request works.

Is there any way to do the equivalent in my retool app?

Any help would be greatly appreciated.


i have same issue the response when calling API is : reason: ","error":true,"queryExecutionMetadata":{"estimatedResponseSizeBytes":145,"resourceTimeTakenMs":22.
is the any way to resolve this problem ?



Hi @jjackson

Do you have 'SSL Certificate Verification' turned on in Postman? It looks like I'm getting the same error when attempting to reach USPTO from Postman:

Is it possible that this is using a custom certificate that's not trusted by default?

Hi @wahyu

Which service are you trying to reach? Could you share a screenshot of the error you are getting?

Hi Ben, If I have 'SSL Certificate Verification' ON, the call fails just like you are seeing. If I disable 'SSL Certificate Verification', the call succeeds. If there would be away from w/in my retool app to turn off SSL Certificate Verification (like they offer in Postman), I'd be happy.

Hi @jjackson

Unfortunately, Retool's cloud offering doesn't allow for disabling SSL verification or using custom CA certificates for REST resource types (there is an open feature request for the latter, however). Our self-hosted offering does allow you to include custom CA certificates (see documentation here).

Hi, we are trying to connect to our rest-api but the cloud version of Retool doesn't recognize the certificate issued by a Public CA.
We get the following message:
"request to failed, reason: unable to verify the first certificate".

How can we trust the chain and the certificate?

Thanks for reaching out @raffru!

The feature request that Ben mentioned earlier has now been shipped:

We have more information here in our docs-- let me know if this helps for your resource! :pray:

Unfortunately, we've got the same problem.

"message": "request to failed, reason: unable to verify the first certificate",
"stack": "MicroserviceError: request to failed, reason: unable to verify the first certificate\n at Object.runQuery (/retool/backend/transpiled/server/modules/dbconnector/dbconnClient.js:413:11)\n at runMicrotasks ()\n at processTicksAndRejections (node:internal/process/task_queues:96:5)\n at async handleHttpRequestStepWithExposedEnvReplacements (/retool/backend/transpiled/server/controllers/resourceAuth.js:167:20)\n at async processRefreshAuthStep (/retool/backend/transpiled/server/controllers/resourceAuth.js:387:36)\n at async /retool/backend/transpiled/server/controllers/resourceAuth.js:421:27"

Hi, are there any news?

Hi @raffru Thanks for checking in! Hmm, is this something you're able to access outside of Retool (in Postman, for example)? If so, can you provide a screenshot of the configuration there?

Additionally, can we see the full resource setup (including the headers & any authentication)?

Hi Tess, thank you for your reply.
Postman works fine.

Below you'll find the resource setup and the postman setting with a reply.

Thank you! Are you able to try adding an auth workflow & then testing the auth workflow?

It looks like this only has a refresh workflow set up:

ok, auth works.
After the test auth and test refresh, I've the same error.

"message": "request to failed, reason: unable to verify the first certificate",

Hi @raffru

It looks like you're using a token in the headers:

You would want to add steps to define this token in the auth workflow.

Currently, it looks like this is only defined in the refresh

Hi Tess,
we don't need first step (authentication) but only an API call to get a token (username and password are already in the header).
So I removed the first step and access_token header variable but the error is the same.

Hi @raffru

It sounds like the main issue is that the Skip CA cert setting isn't going to be applied to the auth section. If you create a new Retool resource where the Base URL is either or and has no authentication set up, you'll see that you get a failed, reason: unable to verify the first certificate when you try to query the resource in an app. If you check on Skip CA Certificate verification, you stop seeing the cert errors when querying the resource.

However, if you add an authentication step that includes calling, the Skip CA Certificate verification setting isn't getting applied to that auth url so you'll get the cert error in the auth workflow

Separately from the cert limitation, is the access token definition. As a general structure, if you want to use a variable token in the resource headers, this should be called and defined in the auth set up, rather than the refresh set up.

1 Like