Skip to main content
Question

Handling OAuth token refresh for Zapier Zaps


Hi all,

I wondered if I could get some advice on how to best handle OAuth access and refresh tokens.

I have built some Zaps which make calls to an API using Webhook by Zapier. The calls must be authenticated with an access token. An access token is valid for 30 minutes and can be refreshed using the refresh token, which is valid for 60 days.

I store the access and refresh tokens in a Zapier Table. I have built a Sub-Zap to refresh the token, which essentially fetches the refresh token from the table, refreshes it, updates the table, and passes the access token through to the Zap that called it.

This works well, but the trouble is that because multiple Zaps are using it, there’s the risk that another Zap calls the Sub-Zap before the first Zap has finished, making the first access token invalid.

I thought about having the Sub-Zap refresh the token every 30 minutes, but this would seem a waste of tasks as the Zaps which need the token don’t run all that frequently.

So I was wondering, does anyone have a good solution for this? I was thinking about maybe recording the expiry date/time and somehow refreshing based on this.

Any advice would be very much appreciated.

Thanks,
Seb

Did this topic help you find an answer to your question?

4 replies

michaeltoth
Forum|alt.badge.img+1

Hey ​@sebyoung,

Nice solution using a Zapier table to store this data! I think that the idea you proposed, storing the expiry date/time and using that to refresh the token, is a good one. That way you don’t refresh more often than is necessary.

You could consider creating a separate Zap that uses Schedule by Zapier to run every day, ideally at a time when your other Zaps are less likely to be running (say, 3 a.m.). This Zap could then check the table, and if the token is set to expire in the next day, perform the refresh function.

You still could occasionally run into issues with other Zaps running at the same time, but it’s much less likely. I’d suggest you also enable autoreplay, which will attempt to rerun any Zaps that fail after a period of time. If the failure was due to an invalid token due to this refresh process, it should then find the updated token and be able to process successfully on the rerun.

Let me know if I can help with any further troubleshooting!


  • Author
  • New
  • 2 replies
  • February 20, 2025

Hi ​@michaeltoth, thanks very much for your response and for the reassurance! I will perhaps experiment with refreshing based on the expiry date. I guess there is still the risk that a token refreshes after a Zap has retrieved it from the Sub-Zap, so it may be a similar situation.

The API I’m calling (Xero) has an integration with Zapier. The integration does not have the functions I need, which is fine, but what’s a shame is that I can’t make API calls via the API Request (Beta) because the integration doesn’t have the required scope to access the endpoints I need. That would have been really great because it would save having to mess about with tokens!


michaeltoth
Forum|alt.badge.img+1

Hey ​@sebyoung

I’ve encountered that same issue with some API Request (Beta) actions. I’m not sure if there is a way to extend the scope to what you need (I haven’t found one) but I agree that would be ideal.

In terms of your problem, one other thing you could consider is implementing some kind of lock mechanism. For example, you could set a flag in your Zapier table while the token is being refreshed or while a Zap using the token is running. Subsequent refresh attempts could check this flag and wait if it's set. This would work something like this:

  1. Zap begins
  2. You set the flag
  3. You use the token
  4. You unset the flag

If a refresh attemps while the token is set, you can use delay before attempting again. With the right configuration, you should be able to get this to work for you and prevent any refresh issues!


  • Author
  • New
  • 2 replies
  • February 20, 2025

Thanks ​@michaeltoth, what a great idea. That sounds ideal!