Looking this information, I ended up with some questions:
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?
Why do I need to retain information not related to my app purposes ?
Also, talking about the data Security and Compliance:
How is going to be tested the information encrypted or hashed inside the database ?
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.
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!
@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.
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.
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) I am unable to get anything other than HTTP 400 in return, with a response payload of precisely the following:
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?
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!
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,
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:
Good insight about the client_id being publicly available!
Thanks to this from Stack Overflow 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:
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.
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.
