OAuth callback URL lockdown



I don’t have anything that I can think of that would help you here right now. You could experiment will callback parameters, but nothing that is configurable on our side.


Yeah we had to scramble too, but parameters appear to pass correctly and you don’t have to lock them. We had to do few redirects based on where we should send the user post authentication.
This is especially a problem with “signin with twitter” workflow, but it all worked out in the end.


Hello @Connexinet ! Thank you very much for your answer.
Do you mean that we will be able to add parameters to the call back url passed to the oauth route and twitter can return back this params in addition to request token?
And in your process , you need theses parameters to achieve redirects ?


Hi @b_reda,
Yes, you are correct.
That’s how it works now, and I hope it stays that way, otherwise we are all in trouble :slight_smile:



I can also confirm that using parameters in the callback URL works. I added a dispatch parameter to the callback URL so I was able to replace 3 call back endpoints with a single, whitelisted endpoint that dispatches appropriately based on the dispatch parameter value.

Problem solved.


It looks like this went live now. I never received any notification about it, so I didn’t discover this change until my app broke. :angry: Is there some way to opt into notifications about breaking API changes?

P.S., the discourse confirmation email was marked as spam.


I’m using Twitter Kit in my product, now I realize that I’ve missed the announcement for a month. So I always receive “Callback URL not approved for this client application. Approved callback URLs can be adjusted in your application settings” every time I try to sign in. Please help me how to fix that. I prefer a way without creating a new application.


Did creating a new app work for you? It didn’t change anything in my case.


Hi, we are also facing this issue and we have over 50 URLs using the oauth, is it possible to use a wildcard for the subdomain or as any part of the URL or is the only option to create a ‘dispatcher’ as implemented by @semifor ?
This is rather urgent for us as this is impacting production sites worldwide.


Please review our announcement from May here, here and here.

You can fix this error very simply, by whitelisting all of your callback URLs in your app settings on apps.twitter.com.


Is there a way for us to add more than 50 URLs to the callback whitelist? I could only add 10 in the web interface. We are working on a fix using a dispatcher script but as I mentioned we are impacting live sites at the moment.


We are also facing an issue with the number of apps we can create wirth one account, we are stuck at 4 but need 5 or 6 to house all the callback urls.


I’ve just added one URL which matches pattern “twitterkit-(consumerKey)://” but it did not work. I assume that there would be a button “Whitelist callback URLs” or something helpful. Actually I found nothing. Could you guide me more clearly? Thanks.


Hi @td0s are you at the UI limit for whitelisting callback URLs? What is your use case for having more than 50 whitelisted URLs?


Hi @robertc Wildcards/patterns at the domain level are not permitted, but querystrings / parameters are possible.


I mean if my consumer key is t6qguwxwIKCj7aCtBKcNqxxxx, the URL will be twitterKey-t6qguwxwIKCj7aCtBKcNqxxxx://. I add no wildcard URL into Callback URLs.


I mean if my consumer key is t6qguwxwIKCj7aCtBKcNqxxxx, the URL will be twitterKey-t6qguwxwIKCj7aCtBKcNqxxxx://. I add no wildcard URL into Callback URLs.


Hi @happycamper
We have an international site available across 30 domains and they each have a desktop and mobile URL for live, QA and development so it adds up to many URLs - we are not too worried about QA and dev for the moment but getting more than 10 callbacks on one app would be very helpful.


While I agree adding more than 10 urls would be good, given that your websites are currently broken and don’t want to wait for all this to happen, it can be solved with few minutes of coding…
Just have one domain as your auth callback and pass the domain you want to redirect to as a parameter, then dispatch the twitter response to the appropriate domain based on that parameter.


Yes, that is the long term solution, deploying the solution to all of the domains will be the time consuming part of the project more than the coding I think.