Hi ​@AUSharePoint,

Thank you for your post.
As you have found, there is no way to be notified before a connection has expired.
To catch expired connections early, you could run a workflow that queries the connection API to find invalid connections. The workflow could be scheduled to run as often as needed.
API documentation: https://developer.nintex.com/docs/nw-api-docs/ref/connections-v1/operations/list-connections

​@SimonMuntz  each time I run this in any form I get a 500 error. Can you provide the steps you took to get that to work?

Hi ​@AUSharePoint,

Does adding your bearer token to the developer page and sending a request as per the GIF below work?
 

Hi ​@AUSharePoint 
Have you resolved the error you received? 

​@SimonMuntz, yes, that does work. 
However, when building out the flow to pull this information in and use it, I am struggling to get it to function correctly. 

Could you provide steps to get these API calls to work with the “call a web service” action?
 

Hi ​@AUSharePoint,

Here is an Xtension that you can add to your tenant. It adds an action to the toolbox.
Note: When creating the connection for the first time, make sure that it is in the format:
Bearer tokenhere.

Example:
 

The following help file explains how to add the Xtension to the tenant. Unzip the attached file before adding.
https://help.nintex.com/en-US/xtensions/01_GetStarted/PRC_01Create_Connector.htm?tocpath=Add%20a%20custom%20connector%20to%20Nintex%20Automation%20Cloud%7C_____0

You can use a Call a Web service action to make the call, but the issue here is that your API key is exposed in the action. Using an Xtension and connection protects the api key.

Thank you! 
I added it to the tenant and tested it. The connection seemed to work without error, and I left the security as default when publishing the Xtension to the tenant. 

It’s pulling back the data now, thank you so much for hanging in there with me. 

​@SimonMuntz,

Something strange has happened. I was able to build out a flow that works perfectly just as you described. 

However, I am unable to create another connection with Get Connections because it has now added 2 additional required API key fields on the connection form. 

My original flow still works, but the personal token only gives me access to the connections I created, even though I have access to all connections. So, I wrote an article on knowledge for others in our team to create their own. They are unable to create a valid new connection because of the additional fields. I tried adding just a space in these fields, which does allow the save, but the connection fails in action.

Do you know what could have happened to add these new fields, and how I can possibly remove them?

Hi ​@AUSharePoint,

I tried to replicate the issue you are seeing, but I am not seeing the same result.
Has the Xtention been changed in any way?
If the issue persists, you could go back to using a Call a web service action.
This is how it is configured.
 

The API does appear to use the permissions of the personal access token.
I tried a Service app but the connection must be shared with everyone for it to get results.
A client app token may be able to be used, but it’s a lot of work to get it functioning.