Thanks! I looked into these possibilities, but I don’t think these any of these scenarios are the answer in this case.
#1: the user’s token is valid for a while (<1 day to several days) before it fails, and they’re not attempting to reauth on the day it stops working.
#2: I don’t think it’s this because we don’t make multiple quick requests with one token like you’re describing. Also, if you’re saying that it would fail temporarily but the refresh token would stay valid, I can confirm that after the event that makes the refresh_token invalid, it stays invalid indefinitely for future requests.
#3: I’m not sure how to match the info we’re receiving in the deauthorization events to the data we have for the user (would the client id be their team? is something in the jwt-decoded data of their token useful? I didn’t see anything that seemed to match), but the timestamps of the deauthorization events we’ve received don’t line up with the user’s timeline of issues and reauthorizations. The only scopes we have are to create and read meetings, so I don’t know how to see the Zoom team’s id (don’t see that in the meeting data).
A new clue? I’ve found since last writing in that whatever event is happening makes ALL the tokens on their Zoom team invalid. Seems like a useful clue, though I’m not sure what possibilities that opens up.
Thanks for your continued help,