Deauthorization endpoint user identification

So I’m attempting to understand how to comply with your requirement to have a Deauthorization endpoint. From what I’ve read on this forum, your suggestion is to use the Account Id that’s passed with the deauth request payload.

So in my case, that means that we have to capture the account id, at the time of authorisation and create a mapping on our side between our customer record and the account Id.

The problem here is that we have an account level OAuth app, which doesn’t appear to support the necessary scopes in order to retrieve the account id.

Please advise.

Hi @dave2,

When you set up your OAuth app, you will provide an endpoint for deauthorization:

When someone uninstalls your app, an event will be automatically triggered and a payload sent to the designated endpoint. This will include the account ID, which you can see in this example:

Let me know if this helps to clarify.


Hi, How do I know which customer on my side that account Id represents?

This is my problem. I thought upon authorization, I could then make a call to users/me to obtain the users account Id, but that doesn’t seem possible due to the available scopes of an Account level OAuth app.

Hey @dave2,

Great question. At the moment, the account owner’s name is not returned alongside the account ID, though this is a good suggestion.

That said, you will be able to see who has installed your app and any activity associated with it in your Marketplace dashboard. This can help to determine who has installed by name:


Hi Will,

I appreciate your help, but you are misunderstanding my problem entirely. Please take a moment to read carefully my message, I understand you have lots to go through but if we keep doing this, this will just add to your workload and not reduce it.

I don’t want the customers name. I’ll try and explain the issue again…

  1. Customer deinstalls the app via zoom,
  2. Zoom makes a call to reauthorization endpoint passing through clientId, account Id etc.
  3. My server then needs to lookup the accountId in a table that maps accountID’s to my internal customer Ids so I know who, on my side, has deauthorized.

My problems are relating to how I establish this table mapping account Ids <-> my customer ids…

As I said, from reading other threads, it is my understanding what I should do is capture the Account Id when a user initialises the connection between my app and zoom.

So once they authenticate, should I then make a call to retrieve the users account Id?

Because I have been unable to do this so far, I do not have the necessary scopes available to retrieve the account id,. This is an Account-Based OAuth app.

So please tell me, how do I retrieve the users zoom account Id at the time of authentication?

Thank you

Hey @dave2 ,

Thank you for clarifying, and my sincere apologies for not catching your concern from the onset. I understand now that you’re essentially looking to make this connection with a customer’s Account ID as soon as they authorize/install the app, so that you can then have this record on your end when they uninstall (but please correct me if I’m misunderstanding).

While there’s not a completely straight forward way to track this, there is a suggestion I can make:

When an account authorizes/installs your app and—as part of the OAuth flow—you send a POST request to to request an access token, you can at that point grab the access_token in the response and JWT decode it. For example, this access_token:

Would decode to something like this, which includes an aid key whose value is the account ID:

If this is feasible, you would be able to store that value on authorization, and then compare it with the value sent to your deauth endpoint in the webhook payload when an account uninstalls:

I hope this is a potential solution, Dave, but don’t hesitate to let me know if there are additional questions about this or if I’ve misunderstood any part of your question.


Many thanks for your response and suggestion, that sounds like a workable solution.

Best Regards,


Glad to hear this might work for you, @dave2!