Updating a Meeting SDK App in Marketplace with SDK used in native iOS and Android

We are in the process of updating our Meeting SDK on the Zoom Marketplace. This app is not intended to be published. There is no plan to use the Zoom Api’s. The sdk’s used for native ios and android in a healthcare app.

We have a Test and Production app.

We noticed the Sdk Credentials or App credentials work the same from a sdk functionality. Is this by design?
authService = MobileRTC.shared().getAuthService()
authService.clientKey = SDK Key or Client ID
authService.clientSecret = SDK Secret or Client Secret

For the “Redirect URL for Oauth” or add Allow list . We don’t have a end point at the moment. We just put a valid urls to our company. Since the Oauth is for Zoom API’s this should be ok?

For the last part when we hit “Add” the page redirects to our valid url.

We noticed in our production non updated meeting sdk app. There is a green “Your app is activated”.


Our updated one just has all the checkmarks, but not the green “Your app is activated” Our testing shows our app works without being activated. Is there any thing to be concerned with not being activated?
Screen Shot 2023-08-02 at 6.29.21 PM

@antcarlson , my responses are inline

This app is not intended to be published. There is no plan to use the Zoom Api’s. The sdk’s used for native ios and android in a healthcare app.

The term Publishing here does not mean that the application is open for public to use. A published application is verified by Zoom. You can still control who will have access to your android and iOS app packages.

Without publishing, the iOS and Android SDK will still work, however you will not be able to join meetings which are created by external accounts.

We noticed the Sdk Credentials or App credentials work the same from a sdk functionality. Is this by design?
authService = MobileRTC.shared().getAuthService()
authService.clientKey = SDK Key or Client ID
authService.clientSecret = SDK Secret or Client Secret

Yes this is by design. Do note that authService.clientKey and authService.clientSecret way of authenticating the SDK will be deprecating.

You will need to sign a JWT token using SDK Key + SDK Secret or Client ID + Clietn Secret in newer versions of the SDK.

What version of the iOS and Android SDK are you current using?

For the “Redirect URL for Oauth” or add Allow list . We don’t have a end point at the moment. We just put a valid urls to our company. Since the Oauth is for Zoom API’s this should be ok?

For the last part when we hit “Add” the page redirects to our valid url.

If you do not publish this application, it is ok to leave it with a placeholder URL.

Our updated one just has all the checkmarks, but not the green “Your app is activated” Our testing shows our app works without being activated. Is there any thing to be concerned with not being activated?

At its current state, your meeting SDK apps will work. But you will not be able to join meetings created by external accounts without publishing.

Thanks for your responses.

You will need to sign a JWT token using SDK Key + SDK Secret or Client ID + Clietn Secret in newer versions of the SDK.
After September 1 we plan to do this in our mobile apps with the newly created meeting sdk.

What version of the iOS and Android SDK are you current using?

Android
Zoom sdk v5.14.5.13410. Which Android version is the last version to support uth method (sdk key, secret),
ios
we are on version 5.13.0.6047 of the meeting SDK, We plan to get the very last version that supports our current auth method (sdk key, secret), which will think is 5.14.5.7861. Is this correct?

@antcarlson

Android
Zoom sdk v5.14.5.13410. Which Android version is the last version to support uth method (sdk key, secret),
ios
we are on version 5.13.0.6047 of the meeting SDK, We plan to get the very last version that supports our current auth method (sdk key, secret), which will think is 5.14.5.7861. Is this correct?

Yes 5.14.5 is the last version supporting sdk key and sdk secret for SDK Auth entered directly in the AuthService

5.14.10 removes this

@antcarlson is this resolved? If so, please let us know!

I support marking this resolved.

1 Like