How to deal with errors and a used refresh token in production

Nathan Wells

We've been implementing some of the Sky API endpoints and during our tests, sometimes we make a mistake and so our code fails to capture the refresh token because of a server error (on our server). So the endpoint is called, but our server doesn't receive the result. The refresh token is then useless because it was used.


This is fine during testing, we can go and easily go through the authorization process again and get another refresh token manually.


But my question is for production code, is there no failsafe? Let's say our code errors for some unforeseen reason - from what I understand, that would leave us without a working refresh token on our live production server.


Because if our code fails, and we don't capture the new refresh code correctly that means all our interaction with the Sky API will be down until someone manually re-authorizes and gets a new refresh token.


I don't really like having that as a possibility. Or am I missing something?


Is there anyway to request that the previous 5 refresh codes continue to work as a bit of a failsafe buffer? Or what is normal practice in this regard?

Dennis Ladnier

Nathan, we may have different use cases which may not be applicable to what you are doing. We have a separate process which obtains refresh token(s) - this separate process makes that current token available to all of our skyapi processes hence our processes are never without a refresh token. Should this separate process fail it auto-recovers (we basically have a 1/2 hr window to recovery) - if there are still issues at ~10mins prior to token refresh I get a text however I can't ever recall the refresh token refresh failing for more than 30mins. We do get network hiccups every now and then but the next try takes care of it.

Nathan Wells

Thanks for your reply Dennis.


We also have a separate process for getting the refresh tokens which then allows everything in our system to have access to the token.


But it sounds like you have run into the same issue I am concerned about - being that you setup texting for when something goes wrong.


It seems like it would be a whole lot better if there was a way for the refresh token to be used again instead of expiring on first use so that we don't have any of these "manual" type of needs.


If we are going to be processing credit card payments and the like through the API, I really don't like the idea of everything breaking because we weren't able to get to a computer fast enough to re-authorize.


There must be a better way?

Steven Cinquegrana

Hi Nathan‍ and Dennis‍,


A while ago, they introduced the preserve_refresh_token option. I think this might be what you're after as if an Access Token refresh fails - for whatever reason, network outage, code bug, etc - you can reuse the existing Refresh Token to get going again without a manual re-auth.


Do a search of the Community on "preserve_refresh_token" and you find some posts by Chris Rodgers‍ explaining its use. The documentation also takes you though it.


I hope I haven't misinterpreted your question, but, in your situation, that's where I'd start looking.


Of course, you will eventually have to accept a new Refresh Token before it expires in 365 days and that is still obviously prone to error, but it's way less frequent and you can build in an explicit flow to manage this "less-off" event.


Cheers,

Steve Cinquegrana | CEO and Principal Developer | Protégé Solutions

Nathan Wells

Thanks Steven Cinquegrana‍ The preserve_refresh_token = true does seem like the best option we have.


I'm also thinking of using two apps for our production code so that if one refresh token fails, we have another through the backup app.


It would be nice if there were a simpler solution though.

Nathan Wells

Looks like there is a feature request regarding this: https://blackbaud-developer.ideas.aha.io/ideas/API-I-283

It would be great if we could get rid of the manual authentication step!