How do I handle API Authentication when a UserID has changed?

Note: A DocuSign member's UserID will only change in very specific circumstances. This guide is intended to assist with those edge cases.

In short, the integration must be able to 're-authenticate' as the user. This may entail clearing a cached UserId or having the user undergo the initial authorization workflow again. 

JWT Authentication

The previous JWT assertion used will no longer be valid. In order to find the new UserID, the Users::List method should be used with the following query string parameters:
This will return a single record with the correct ID for the email address in question.

 Note that the Users::List method requires administrative access. If the changed user was the only admin on the account, they will need to log in to the web console to retrieve their User ID.

Access Code Grant Authentication

Any existing refresh tokens should be considered invalid. If the application is storing the user's ID it should be cleared and reset. 
The user should be directed to the application's Authorization URL so they can log in and have a new code generated. Once that code is exchanged for the Bearer token, the UserInfo method can be used to get the new User ID.

Legacy Header Authentication

If an email address was being used for either the <Username> or <SendOnBehalfOf> parameter, it will continue to function. If the GUID was used, the Users::List method should be used as documented in the JWT Authentication section above.