OAuth Redirect URL query parameter lost after user login

The ‘Redirect URL for OAuth’ for my app contains multiple query parameters:
https:// cp. clr. events / ?option=com_jbooka&task=zoom.authenticated

When initiating the OAuth flow from our website to obtain Zoom account access for a user, all works fine if the user is already logged into their Zoom account in their current browser session at the time.

However, we have found that if the user is not already logged into their Zoom account (and so is directed to the login page before the authorisation page), on redirecting the user back to our site, the ‘task’ parameter has been lost from the query string. Instead, we only get 'option, ‘code’ and ‘state’ parameters back. This is resulting in us not being able to correctly process the redirect after successful authorisation by the user.

As described above

Which App Type (OAuth / Chatbot / JWT / Webhook)?

Which Endpoint/s?
https:// marketplace. zoom. us /docs/api-reference/using-zoom-apis#using-oauth

How To Reproduce (If applicable)
Steps to reproduce the behavior:

  1. Ensure user is not logged into Zoom account
  2. Initiate OAuth authorisation flow from ClearBookings dashboard. That is, user clicks a button with the following link:


  1. User is presented with login page, enters credentials and authorises use of Zoom account.

At this point, the Location header in the 302 response returned is as follows (note the redirect_uri parameter is no longer in encoded form here):


And then the above URL returns a 302 response with Location header as follows:

https:// cp. clr. events/?option=com_jbooka&code=3jfHBzLY05_ihwjqmk1QQCDXPXtQpFHJw&state=122670

Best guess is that decoding of the redirect_uri during the login process is causing the loss of the query parameter, though it is not clear why the state parameter or others are not also impacted.

Screenshots (If applicable)

Additional context
Had to mangle URLs above due to ‘new user’ URL limitation

Hey @johnrix,

Query params are not supported in redirect urls currently. You will need to utilize the state query param, and then do any further redirects / logic on your redirect url page.



Thanks for your reply Tommy.

I actually set up a URL shortener in our system last night to remove the query parameters from it:


and updated our integration code to use this everywhere in place of the old URL. However, even after double and triple-checking my code, I couldn’t get past a ‘Redirect URI mismatch’ error I was getting when requesting the first access token. I found the only way I could get around this was actually to re-introduce the first of my original query parameters into my code (though I actually didn’t add this into the app configuration on my Zoom account)!


I suspect the problem may have been somehow related to how I was adding the state parameter to the end of the redirect URI and perhaps not encoding it correctly (I’m not certain off-hand what the URL spec has to say about multiple question marks in a URL).

If you have any thoughts on why it wasn’t working without me including that extra query parameter, I’d be interested to hear them, though it isn’t critical at this point since I’ve been able to work around it anyway.

On a final note though, there is no mention either in the documentation or on the app setup page about Redirect URIs not supporting query parameters. It was also only due to me testing scenarios where I was not already logged into my Zoom account that I caught this on our side, so is likely to catch other developers out also. It would be prudent to add a note about it in the documentation.

Hey @johnrix,

Can you confirm your redirect url is the same for the redirect url field and whitelist url in your marketplace app settings, as well as when making the OAuth requests?

We will add the query param in redirect url limitation to our docs. CC @shrijana.g, @michael.harrington.


Hi @tommy,

strangely, when re-testing the auth process again today, I started receiving the mismatch error with my workaround in place. I have now removed that and all is behaving correctly. I have no good explanation for what went wrong previously - can’t even think of any sort of caching issue that may have been the culprit, but I think we can put this one to bed anyway.

Much appreciated on the documentation follow-up!

Kind Regards,

Hey @johnrix,

Strange! Glad to hear it is working now! :slight_smile: