OAuth callback URL lockdown



I somehow missed the OAuth callback URL lockdown announcement. Saw it in a retweet. Had a moment of panic due to the short timeframe: June 8th.

So, attempted to register Followerwonk’s callback URLs. I need to register 18. It only accepts 10.

Why so many? Two domains—site migration coming up soon and we’ll run in parallel for a bit: moz.com/followerwonk and followerwonk.com. Three environments: dev, staging, production. Three callbacks: sign-up with Twitter, login with Twitter, connect a Twitter account. 2 x 3 x 3 = 18.

I haven’t checked the docs or experimented with it, yet, but I wonder if it accepts extra parameters and passes them back.

Accepting a prefix that includes a fully qualified domain would help. Wildcarding subdomains would also help.

If nothing else, I’ll have to cache the internal callback action with the request token and redirect accordingly. But that some implementation work I hadn’t planned and I’m already on a really tight schedule for the site move.

I could use a little help here, Twitter. :wink:


I would recommend you use a separate app for dev, staging, and production. Especially since your production secrets should not be available to developers in a development environment.


That’s the advice from our product team also; however this is a new change so we are listening to feedback from a multitude of developers and we appreciate questions like this from Marc!



we have the same questions here, since our twitter app offer the possibility is used by our customers to answer to other twitter users DM or to fetch tweet that refers to our customers ( through mentions or hastags ).

Since we have an url by customer ( ex: https://.domain.com/<version, ex : 8.2>//file.ext?param1=1&param2=2 ), whitelisting all these urls will be a tedious work …
Is there any extra callback params that could be forwarded in order to identify our customers and do the match or is there any possibility to allow wildcards ?
Do you have any advice or any good pratices to achieve this ?

Thank in advance for your answer !



@andypiper Followup questions.

Will the ‘oob’ callback parameter still be honored for desktop applications and scripts? And if so, does it need to be whitelisted?

If I create a new app for testing and set “Enable Callback Locking”, will it behave exactly the same as the post- June 12th change? If so, I can answer some of these questions myself and get me OSS library docs updated.



Yes it will be hono(u)red. No, it does not need to be whitelisted (and cannot be).

That is my understanding, yes; it’s certainly been my experience, having implemented that on some of my own apps now.


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?