Our Server-to-Server OAuth application uses APIs that are similar to the ones you use, and we only handle rate limiting and the refresh token.
For rate limiting, we aren’t sensitive to errors because we store in our system what the desired configuration should be, then an on-demand or periodic process will compare that to what Zoom has and make changes to bring Zoom into alignment with what we want it to be. Even if there’s an error, we’ll retry later on and compare again. So we don’t specifically handle this error.
For the refresh token, the behavior we have for our Server-to-Server OAuth application might be different from the kind of application you’re building. For high availability, we had to implement our own key rotation strategy. I’ve outlined a proposed two-key rotation strategy if you have a shared database that relies on exactly one process succeeding on an UPDATE / WHERE statement matching the original renewal time. This was implemented at a time when Zoom only supported one valid access token at a time per application; that access token limitation is relaxed now but I don’t have experience with the new behavior, as we haven’t updated to account for that. If you’re building a different kind of OAuth application, this might not apply to you.