# Data Compliance API - Deauthorization Endpoint URL

**URL:** <https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870>\
**Category:** API and Webhooks\
**Created:** [April 5, 2019, 5:17pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870 "2019-04-05T17:17:11Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![karol.garcia](https://avatars.discourse-cdn.com/v4/letter/k/3bc359/32.png) [@karol.garcia](https://devforum.zoom.us/u/karol.garcia)\
**Post date:** [April 5, 2019, 5:17pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/1 "2019-04-05T17:17:11Z")

</div>

Hi Everyone,

I’m creating an APP for the marketplace, the scopes the application are the following:

- View your meetings (meeting:read)
- View your recordings (recording:read)

Looking the documentation about the data compliance and the deauthorization, I noticed the following:

 ![Data%20Compliance%20-%20Security%20and%20Compliance%20-%20Zoom%20App%20Marketplace%20-%20Documentation%20-%20Zoom%20Developer%20-%20Technical%20Documentation%20and%E2%80%A6%202019-04-04%2023-34-03](https://us1.discourse-cdn.com/flex016/uploads/zoomdeveloper/original/1X/a02ecbd4b976729f70b7361bb9b7a3536b621c68.png)

Looking this information, I ended up with some questions:

1. My application only have rights to read meetings and recordings, by saying this, to be specific, we only store the tokens, which are already encoded, we do not store any sensitive user information, so, this normative is going to be mandatory for us in order to have the application approval?

2. Why do I need to retain information not related to my app purposes ?

Also, talking about the data Security and Compliance:

1. How is going to be tested the information encrypted or hashed inside the database ?

Regards,

Karol Garcia,

---

<div class="post-metadata">

**Author:** ![ojus.zoom](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/ojus.zoom/32/734_2.png) [@ojus.zoom](https://devforum.zoom.us/u/ojus.zoom)\
**Post date:** [April 5, 2019, 8:36pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/2 "2019-04-05T20:36:54Z")

</div>

Hi,

Please accept our apologies for the inconvenience caused. We found some bugs in the data compliance docs, and since we have hidden it.

I will respond here when we have updated it and its available to use.

Thanks.

---

<div class="post-metadata">

**Author:** ![tbryant](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/tbryant/32/2065_2.png) [@tbryant](https://devforum.zoom.us/u/tbryant)\
**Post date:** [April 29, 2019, 4:31pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/3 "2019-04-29T16:31:00Z")

</div>

We have been waiting on this for 24 days. Can we get an update? Karol is developing this application for us. We can not proceed unless this is addressed. Please advise.

Todd

---

<div class="post-metadata">

**Author:** ![ojus.zoom](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/ojus.zoom/32/734_2.png) [@ojus.zoom](https://devforum.zoom.us/u/ojus.zoom)\
**Post date:** [April 29, 2019, 6:06pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/4 "2019-04-29T18:06:06Z")

</div>

Hi @tbryant,

Thank you for patiently waiting as our team is still working on resolving those bugs. I completely understand, how important this documentation is to your workflow and I can see how frustrating it would be.

Once again, I am sorry it is taking us this long to resolve the problem, and we look forward to provide a resolution earlier than this in the future.

As mentioned in the previous post, I will post on this thread, once the we update the documentation. If you want me to send you and email, regarding the resolution, please send a PM to me with your email address, and I will update you as soon as possible.

If you have any further questions or concerns, please let me know. I’m here to help!

Thanks,

---

<div class="post-metadata">

**Author:** ![tbryant](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/tbryant/32/2065_2.png) [@tbryant](https://devforum.zoom.us/u/tbryant)\
**Post date:** [April 29, 2019, 6:18pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/5 "2019-04-29T18:18:34Z")

</div>

Thank you for getting back to me. Do you have a timeline on this or a work around for now? Let me know.

Thanks,

Todd

---

<div class="post-metadata">

**Author:** ![ojus.zoom](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/ojus.zoom/32/734_2.png) [@ojus.zoom](https://devforum.zoom.us/u/ojus.zoom)\
**Post date:** [May 1, 2019, 10:07pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/6 "2019-05-01T22:07:08Z")

</div>

Hi @tbryant,

Currently, we do not have a definite timeline, but I will update this thread as soon as we update the docs.

Apologies for the inconvenience caused.

Thanks,

---

<div class="post-metadata">

**Author:** ![tbryant](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/tbryant/32/2065_2.png) [@tbryant](https://devforum.zoom.us/u/tbryant)\
**Post date:** [May 2, 2019, 4:48pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/7 "2019-05-02T16:48:09Z")

</div>

Please let me know if there any option that can replace the Data Compliance API - Deauthorization Endpoint URL.

Thanks,

Todd

---

<div class="post-metadata">

**Author:** ![ojus.zoom](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/ojus.zoom/32/734_2.png) [@ojus.zoom](https://devforum.zoom.us/u/ojus.zoom)\
**Post date:** [May 3, 2019, 9:44pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/8 "2019-05-03T21:44:01Z")

</div>

@tbryant, Unfortunately, there is no workaround for the Data Compliance API - Deauthorization Endpoint URL. But as mentioned, our Engineers are working diligently to resolve the issue, and I will update this thread, as soon as the issue is resolved.

Thanks,  
Ojus

---

<div class="post-metadata">

**Author:** ![tbryant](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/tbryant/32/2065_2.png) [@tbryant](https://devforum.zoom.us/u/tbryant)\
**Post date:** [May 6, 2019, 9:34pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/9 "2019-05-06T21:34:22Z")

</div>

So if we use this method for OAuth, will our application be approved?

> **[OAuth with Zoom - Authorization - Documentation](https://marketplace.zoom.us/docs/guides/authorization/oauth-with-zoom#refresh-access-token)**
>
> OAuth with Zoom
> 
> Overview
> 
> OAuth 2.0 is the industry-standard authorization protocol that allows applications to obtain requested access to user account...

Please let me know.

---

<div class="post-metadata">

**Author:** ![ojus.zoom](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/ojus.zoom/32/734_2.png) [@ojus.zoom](https://devforum.zoom.us/u/ojus.zoom)\
**Post date:** [May 6, 2019, 10:07pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/10 "2019-05-06T22:07:03Z")

</div>

@tbryant,

Currently, since our Data Compliance API & Deauthorization Endpoint URL are under development, we do not consider those as a criteria for approving an App.

If your application satisfies all the other criteria, your app should be approved. If your app is not approved, you will receive an email from the Marketplace team to about the updates that you would need to do to get your app approved.

Please let me know if you have any other questions.

Thanks,  
Ojus

---

<div class="post-metadata">

**Author:** ![bdeanindy](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/bdeanindy/32/154_2.png) [@bdeanindy](https://devforum.zoom.us/u/bdeanindy)\
**Post date:** [August 16, 2019, 8:44pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/11 "2019-08-16T20:44:38Z")

</div>

The Data Compliance API is live and documented here: [https://marketplace.zoom.us/docs/guides/authorization/deauthorization](https://marketplace.zoom.us/docs/guides/authorization/deauthorization)

---

<div class="post-metadata">

**Author:** ![john](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/john/32/1810_2.png) [@john](https://devforum.zoom.us/u/john)\
**Post date:** [September 12, 2019, 10:41pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/12 "2019-09-12T22:41:51Z")

</div>

Hello, thanks for putting up the Compliance API documentation!

I’ve notice two things wherein the documentation doesn’t line up with what’s observed:

1 - I see no `authentication` header in the Deauthorization Event Notification webhook POST (i.e. HTTP\_CLIENTID, for example, is set, but HTTP\_AUTHENTICATION is not). Indeed, my app’s `Verification Token` isn’t present anywhere in the payload.

2 - When posting a reply back to `https://api.zoom.us/oauth/data/compliance` (to report `compliance_completed` as described [here](https://marketplace.zoom.us/docs/api-reference/data-compliance/data-compliance/compliance)) I am unable to get anything other than HTTP 400 in return, with a response payload of precisely the following:

`{"reason":"Internal Error","error":"invalid_request"}`

This might well be user error, but I have no clue as to what that error might be. The Basic Authentication I’m using is precisely as is working in calls to other API endpoints, and I’ve triple checked the POST data fields to match what is expected.

Given the provided reason of “Internal Error”, is this functionality perhaps not quite fully ready for use?

---

<div class="post-metadata">

**Author:** ![tommy](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/tommy/32/72769_2.png) [@tommy](https://devforum.zoom.us/u/tommy)\
**Post date:** [September 13, 2019, 8:29pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/13 "2019-09-13T20:29:20Z")

</div>

Hey @john, thanks for posting and using Zoom!

> [@john](#):
>
> 1 - I see no `authentication` header in the Deauthorization Event Notification webhook POST (i.e. HTTP\_CLIENTID, for example, is set, but HTTP\_AUTHENTICATION is not). Indeed, my app’s `Verification Token` isn’t present anywhere in the payload.

The Verification Token is present under `{requestObject}.headers.authorization`.

[Here is an example in Node.js / Express.](https://github.com/zoom/unsplash-chatbot/blob/master/index.js#L159)

> [@john](#):
>
> 2 - When posting a reply back to `https://api.zoom.us/oauth/data/compliance` (to report `compliance_completed` as described [here](https://marketplace.zoom.us/docs/api-reference/data-compliance/data-compliance/compliance)) I am unable to get anything other than HTTP 400 in return, with a response payload of precisely the following:

[Here is a working example of a request to the POST /oauth/data/compliance endpoint.](https://github.com/zoom/unsplash-chatbot/blob/master/index.js#L163)

If these examples don’t help solve the issue, can you please post your request body here so I can debug (remove any sensitive information)?

Thanks,  
Tommy

---

<div class="post-metadata">

**Author:** ![john](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/john/32/1810_2.png) [@john](https://devforum.zoom.us/u/john)\
**Post date:** [September 16, 2019, 3:22pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/14 "2019-09-16T15:22:46Z")

</div>

Hi Tommy,

Thanks! I still don’t see my app’s `Verification Token`: I’m working in PHP so I would expect to find it (I think!) in the incoming request’s headers (as obtained from PHP’s `apache_request_headers()` function, or directly in `$_SERVER['HTTP_{uppercaseHeaderName}']`, i.e. `$_SERVER['HTTP_AUTHENTICATION']` in this case).

Even if I’m looking it up in the wrong way I would expect to see that token value present SOMEWHERE in the payload, but I don’t. Perhaps this is because my app is still not yet approved for the marketplace?

Nevertheless, I figure requiring a match on the client\_id HTTP header (which is present as expected), plus all the other values that have to line up, enables my code to be pretty darn sure that the request originated from Zoom!

To the other issue, that Node.js example you gave me was super helpful: I see now that sending the `'Content-Type: application/json'` header and sending the payload as JSON encoded is the key. (I had been doing form-based postings of the payload, which was wrong and presumably the cause of the “Internal Error” message.)

So on balance I’d say I’m good; thanks again for your help!

Cheers,  
John

---

<div class="post-metadata">

**Author:** ![tommy](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/tommy/32/72769_2.png) [@tommy](https://devforum.zoom.us/u/tommy)\
**Post date:** [September 16, 2019, 8:50pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/15 "2019-09-16T20:50:12Z")

</div>

Hey @john!

You are correct, you will only receive the Deauthorization Event Notification Webhook with the Production version of your app. You can test this by installing the production version of your app via your apps publishable URL,

![54%20PM](https://us1.discourse-cdn.com/flex016/uploads/zoomdeveloper/original/2X/e/e8fb332fb667a2fa25aea412ebcb6e0a16a87b00.png)

And then [uninstalling your app on your “Installed Apps” page.](https://marketplace.zoom.us/user/installed)

 ![21%20PM](https://us1.discourse-cdn.com/flex016/uploads/zoomdeveloper/original/2X/f/f35619fd8c7545393bd20b61fd974db29f919867.png)

* * *

I made a simple PHP web server and was able to see the `Verification Token` in the request headers (when testing a Zoom event/webhook sent to my server). Here is my code:

Example 1.

```php
<?php

error_log(print_r($_SERVER, true))

?>

```

![41%20PM](https://us1.discourse-cdn.com/flex016/uploads/zoomdeveloper/original/2X/b/beaf910c28cb7695f4006ff0b30c8c728be03531.png)

Example 2.

```php
<?php

error_log(print_r(getallheaders(), true))

?>

```

 ![48%20PM](https://us1.discourse-cdn.com/flex016/uploads/zoomdeveloper/original/2X/1/1bf0a70290f9c39752b886851443e91644f876b2.png)

> [@john](#):
>
> Nevertheless, I figure requiring a match on the client\_id HTTP header (which is present as expected), plus all the other values that have to line up, enables my code to be pretty darn sure that the request originated from Zoom!

[Just FYI your client\_id is publicly available via the install url.](https://marketplace.zoom.us/docs/guides/authorization/oauth/oauth-with-zoom#authorization-code) So I would use the Verification Token to verify the requests are coming from Zoom as the Verification Token is not publicly available.

Example:  
`https://zoom.us/oauth/authorize?response_type=code&client_id={YOUR_CLIENT_ID}&redirect_uri={https://YOUR_REDIRECT_URI}`

> [@john](#):
>
> To the other issue, that Node.js example you gave me was super helpful: I see now that sending the `'Content-Type: application/json'` header and sending the payload as JSON encoded is the key. (I had been doing form-based postings of the payload, which was wrong and presumably the cause of the “Internal Error” message.)

Happy to hear you figured it out 🙂

Let me know if you have any other questions!

Thanks,  
Tommy

---

<div class="post-metadata">

**Author:** ![john](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/john/32/1810_2.png) [@john](https://devforum.zoom.us/u/john)\
**Post date:** [September 18, 2019, 5:59pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/16 "2019-09-18T17:59:54Z")

</div>

Hi Tommy,

Good insight about the client\_id being publicly available!

Thanks to [this from Stack Overflow](https://stackoverflow.com/a/51826972/556250) I figured out why `HTTP_AUTHORIZATION` was missing from the `$_SERVER` variables. I just needed to add this to my htaccess file to make it appear:

`SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0`

I’m good to go, thanks again!  
John

---

<div class="post-metadata">

**Author:** ![tommy](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/tommy/32/72769_2.png) [@tommy](https://devforum.zoom.us/u/tommy)\
**Post date:** [September 18, 2019, 9:26pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/17 "2019-09-18T21:26:48Z")

</div>

Hey @john, happy your issue was resolved 🙂

Apologies for not sharing my `.htaccess` file in my post above ^

Happy building!

-Tommy

---

<div class="post-metadata">

**Author:** ![zeus](https://avatars.discourse-cdn.com/v4/letter/z/a4c791/32.png) [@zeus](https://devforum.zoom.us/u/zeus)\
**Post date:** [October 7, 2019, 6:24pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/18 "2019-10-07T18:24:51Z")

</div>

We are facing the same issue as raise by the OP.

Has there been an update to the endpoints/interfaces to allow applications that only need `meeting` related endpoints to be able to determine which account a deauthorization event notification refers to?

If not, does this mean the deauthorization event handling is not required for compliance?

Are there any plans to include the account\_id along with the payload that returns the refresh token during the oAuth process? Doing so would allow us to store the account\_id along with the credentials which would enable us to lookup the account referenced in a future deauthorization notification.

---

<div class="post-metadata">

**Author:** ![tommy](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/tommy/32/72769_2.png) [@tommy](https://devforum.zoom.us/u/tommy)\
**Post date:** [October 9, 2019, 11:51pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/19 "2019-10-09T23:51:17Z")

</div>

Hey @zeus,

Apologies for the late reply!

> [@zeus](#):
>
> Has there been an update to the endpoints/interfaces to allow applications that only need `meeting` related endpoints to be able to determine which account a deauthorization event notification refers to?

The Deauthorization endpoint is meant to notify your server when an app is uninstalled, after which you notify Zoom that you have cleared out any user data you may have retained.

If you do not retain any user data at all, you still have to notify us.

[https://marketplace.zoom.us/docs/guides/app-lifecycle-management/data-compliance#notify-zoom-of-data-compliance](https://marketplace.zoom.us/docs/guides/app-lifecycle-management/data-compliance#notify-zoom-of-data-compliance)

> [@zeus](#):
>
> Are there any plans to include the account\_id along with the payload that returns the refresh token during the oAuth process?

If you [JWT parse](https://jwt.io/) (their are code libraries that do this) the access\_token, you will see the account\_id in the object. 🙂

Let me know if you have any other questions!

Thanks,  
Tommy

---

<div class="post-metadata">

**Author:** ![DeveloperBot](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/developerbot/32/12632_2.png) [@DeveloperBot](https://devforum.zoom.us/u/DeveloperBot)\
**Post date:** [August 21, 2020, 6:28pm UTC](https://devforum.zoom.us/t/data-compliance-api-deauthorization-endpoint-url/3870/20 "2020-08-21T18:28:12Z")

</div>


