Can't get direct messages? Read, Write and Access direct messages enabled


We couldn’t access twitter direct messages via our application, so we updated the application access to:
Read, Write and Access

but the oauth authorize app page still says:

This application will not be able to:

  • Access your direct messages.
  • See your Twitter password.

How long does it normally take for the Access to be reflected in the application? Any thoughts?


Hi @bwebtemplates,

Are you using oauth/authenticate or oauth/authorize for the user-entering-their-credentials step of OAuth? oauth/authenticate will not negotiate new RWD-permitted tokens but oauth/authorize will.


I’ve got this problem as well. I’m using Abraham’s PHP library. It don’t understand what Taylor means by “oauth/authenticate or oauth/authorize”. Am I able to control this myself?


Never mind. Works as advertised.


how did you get it to work?


I am having this problem aswell, even though the app was for Read, Write and Direct Messages. I am not sure what happened, but how did everyone fix this?


same problem here, also using Abraham’s PHP library. I hope, @beders will share his solution.


I don’t have a special solution for you. Make sure you update your application permissions and have your users re-authorize the app.


Thanks for the update, I found a different way to solve the problem:
In your redirect.php search the line
"$url = $connection->getAuthorizeURL($token);" (or so)
and change it into:
"$url = $connection->getAuthorizeURL($token,true);"
Now the user is forced to login and authorizes the application.
Have a look at the “getAuthorizeURL()” function!


I seem to still have this issue and can’t seem to locate the issue. Any help please??? It is oauth/Authorize and I tried @rain_room solution, I’m using Abraham’s PHP library and doesn’t work.


@rain_room But we don’t want the users to ALWAYS have to log-in, right? What’s the best way to have them log in ONLY ONCE to upgrade to DM, and then never have to see that screen thereafter?


All - let me attempt to clarify the problem / question. I’m not sure it’s been stated.

Suppose that web application X wants their users to “Sign in with Twitter.” They want to send their users to a single Twitter URL that:

(1) sends them right back to the website if they’ve already granted all permissions
(2) asks that they “upgrade” to DM if they previously only had R&W access
(3) asks them to grant R&W&DM if the user has never seen them before.

This is, I imagine, the most popular use-case scenario that any app could possibly face. What is the URL for this to work? Is it authorize, authenticate? Do we pass in force_login or not? Does this work with @abraham’s PHP library?


Unfortunately there isn’t a single URL which will accomplish what you want. You can get something close to this flow if you follow these steps:

1.) Use /oauth/authenticate in order to let users “sign in” to the app, which will result in a read/write only token the first time the user signs in.
2.) Once signed in, prompt the user to see whether they wish to enable DMs.
3.) If yes, redirect the user to /oauth/authorize. Once this flow is done, store the new read/write/DM token, and note that the user has enabled DMs in the app data store.
4.) Future “Sign in with Twitter” calls through /oauth/authenticate will return a read/write/DM token.
5.) Check the “enabled DMs” flag in the data store to see whether to prompt the user to upgrade the token, and for any branching logic that requires DM access to be present.


I am also facing problem to get the Direct messages with Xauth approach. I have gone throgh developer kit and suuccessfully get the Direct messages with Oauth approach. But I don’t want to include OAuth approach as it leads to drastic changes to my app(Desktop app).


Direct message access is not available when acquiring access tokens through xAuth.


Thanks Taylor, yup i know this, but i have some areas in my app where i can’t open a browser(an app using different data layer from the original app). Here i am not able to authenticate. I code i have provided the same verifier generated at app level to this app also but failed to authenticate.


Further i am having another problem with oAuth approach, i am not able to change the profile pic as it also fails to authenticate.


What mean you found the good solution of you problem?


Yeah, that’s what I was afraid of. See, now I (as a developer) have to start keeping track of which users I’ve gotten DM access from, so that I can decide whether or not to prompt them.

Maybe there’s a way I can ask Twitter who has DM access? SInce Twitter has to keep track anyway… but this is all kind of a mess, I wish developers just had a single URL they could configure to achieve the desired behavior. Makes me want to move back over to Facebook! :wink:


Well if you’re keeping track of the user’s token you must have a persistence store. Hopefully adding a bit field into that store isn’t too much of a difficulty. I’ll agree that this isn’t the most direct flow, but it really is more of an exception with the API, not the norm.

The way to determine whether a user has DM access would be to try and load their DM feed - an error response should indicate that the token does not support DMs: