User `status` field differs in `config()` response vs `getMyUserContext()` response

in the Advanced React Sample App, you listen on onMyUserContextChange;

zoomSdk.addEventListener("onMyUserContextChange", (event) => {

(Taken from the code in Authorization component in the repo here)
See your docs on the onMyUserContextChangeEvent here

However, when examining the Typescript types the npm package, there does not seem to be a status field on this onMyUserContextChange event;

declare type OnMyUserContextChangeEvent = {
    /** Timestamp at which the user's context change */
    timestamp: number;
    /** Role of the user */
    role: 'coHost' | 'attendee' | 'host';
    /** Screen name of the user */
    screenName: string;

(Taken directly from @zoom/appssdk npm package)

Also in the same Advanced React Sample App, you check whether a user is in Guest mode by looking at either the config() response, or at the response from getUserContext() (in this case, userContextStatus is set to be either of those response values)

if (userContextStatus === "authorized") {
} else if (
  userContextStatus === "unauthenticated" ||
  userContextStatus === "authenticated"
) {

this userContextStatus is initialized to be the auth.status field of the ConfigResponse;

declare type AuthObject = {
    status: 'authorized' | 'unauthorized';
    upgradable: boolean;

declare type ConfigResponse = {
    /** The context in which the Zoom App is launched: inMeeting, inWebinar, inMainClient, inPhone. */
    runningContext: RunningContext;
    /** Unsupported JS APIs and events. */
    unsupportedApis: Apis[];
    /** Version of the Zoom Client in which the app is running. */
    clientVersion: string;
    /** 'webview2/xxxx', 'cef/xxx', 'applewebkit/xx' */
    browserVersion: string;
    /** 'authorized' or 'unauthorized' */
    auth: AuthObject;
    /** only available in meetings. Provides the specifications of audio and video */
    media?: MediaObject;
    /** provides the browser userAgent*/
    userAgent: string;
     * @hidden
     * (Supported starting in client version 5.11.0)
     * the product that this app is being run on
     * */
    product?: 'desktop' | 'mobile' | 'personalZoomRoom' | 'web' | 'sharedZoomRoom';

The auth.status value in the config() response seems to be only 'authorized' | 'unauthorized', whereas when calling getUserContext(), the response includes a status field that takes 'unauthenticated' | 'authenticated' | 'authorized';

declare type GetUserContextResponse = {
     * | status |	Description |
     * | ------- | -------- |
     * | unauthenticated | Not signed in with Zoom. |
     * | authenticated | Authenticated with Zoom, but did not add the app. |
     * | authorized | The user has added the app and granted the required scope permissions. |
    status: 'unauthenticated' | 'authenticated' | 'authorized';
    /** The name of the Zoom user as it appears in the meeting */
    screenName: string;
    /** A temporary participant-identifier - changes each time users join meetings or navigate between breakout rooms */
    participantId: string;
    /** A meeting-specific participant-identifier - it persists as users navigate between breakout rooms or briefly loses connections */
    participantUUID: string;
    /** The role of the Zoom App user in the meeting. Values: 'host', 'coHost', 'attendee', 'panelist' (webinar only) */
    role: string;

Sorry for the long write-up, but I’ve been deep in trying to implement in-client OAuth and referencing the example app above.

Is there a mistake somewhere in the types? Should each of these status values be of the same type?

For the time being, we are following the convention of the sample app by calling getMyUserContext() once config() succeeds, in order to get the user’s status rather than using auth.status on the config() response.

@om7 Thanks for bringing this up. I think it’s important for our typings to be consistent. I pinged our engineering team to see if this is something we plan on unifying going forward and will get back to you when I have confirmation on our plans.

I’m glad to hear that you have a workaround for now.

1 Like

Thanks @MaxM. Appreciate the response!

@om7 No problem! We’re working to make sure that going forward we are using consistent types especially when it comes to UserContext.

I’ll reach out when we update the SDK.