API Expiry Refresh Token issue

Hi Team, We are syncing user data from a Wordpress website to Keap. But as we all know, the API keys/token expire every 24 hours. But we have a crone job running, which will get a new token (I got this idea from the keap community). It’s working fine initially, but after some time, it stops working, and no error log can be found in the crone job. What can be the issue? Can the API keys not expire?

Hi Jon, you are not the only developer experiencing this issue.

A few days ago another developer was reporting the same issue here:

I also heard from another developer that their integrations have been experiencing Token drop outs as well. They have to re-authorise the connection every so often.

I recommend that you create a Developer Support Ticket to report the issue.
https://developer.infusionsoft.com/support/tickets/create/

Keap API team (@TomScott) need to investigate the issue because there seems to be a problem with the OAuth Token mechanism.

We have investigated several similar tickets and each has resolved to programmatic error on the client side, in all but one case being due to bad multithreaded requests cycling the Refresh Token and dropping the new Refresh Token, leaving the client without the correct Token to use to retrieve the next Access Token/Refresh Token pair. I am not aware of any open tickets that have not been investigated to this result.

As far as technology, our token management and authentication is fronted by Google Apigee specifically to ensure that we have sufficient capacity and reliability to provide these services to our integrators.

@TomScott - The problem is that not all developers will be raising tickets, some will just reauthorise the connection again.

Did you check this thread below? @Cliff_Field had a thought that if the User reset their Password, would it affect the Access Token?

If you are saying that the majority of errors are on the client side, then what is the correct procedure in handling the tokens? If you have a Cron Job running every 24 hours getting and storing the tokens then that would be sufficient.

It seems to me that developers should be logging all the token requests and responses. Then if the issue occurs again that will give you a better idea where the problem could be.

@TomScott - Would it be possible to explain to us how the Tokens are generated in the first place?

Are they generated within Keap processes and passed to Apigee, or are the tokens fully generated by the Apigee service?

User login credentials are not directly related to the authorization for integrations; we use an internal user identifier rather than relying on the username or password.

The cron job is the correct procedure, but the cases we have identified are insufficient trapping around retries, where the first request was made but causes a retry while the first is still in-flight for some reason. The second request fails because the Refresh Token is no longer valid, and the first call’s returned Refresh Token is swallowed.


The tokens are generated and authenticated entirely within Google Apigee, yes.