New permission level enforcement happens this Thursday (30th June)

[Matt Harris]

Hey everyone,

Just a quick reminder that we'll be enforcing the new permission level this Thursday, 30th June. 

When we enforce the new permission level Read (R) and Read & Write (RW) access tokens will be unable to use the following API methods:

/1/direct_messages.{format}

/1/direct_messages/sent.{format}

/1/direct_messages/show.{format}

/1/direct_messages/destroy.{format}

Any requests made to those endpoints with R or RW tokens will receive an HTTP 403 Forbidden error with the response body:

    {"errors":[{"code":93,"message":"This application is not allowed to access or delete your direct messages"}]}

Some key points

* If you do not need to read or delete a user's direct messages you do not need to do anything. You can always ask a user to reauthorize at a greater permission level.

* Existing tokens will still work but only those with Read, Write, and Direct Messages access will be able to read and delete direct messages.

* Read & Write access tokens can still send direct messages.

* You can verify the permission level of the token you are using by inspecting the X-Access-Level header. This header is included when a successful OAuth request is made to the API.

* When a user reauthorizes your application at the Read, Write, and Direct Messages (RWD) level, the oauth_token returned by the https://api.twitter.com/oauth/access_tokenrequest will be different than the one you already have. This is because we issue new tokens whenever the permission level is changed. If the permission level is the same the token is not recreated, e.g. you have an RWD token and you ask the user to reauthorize at RWD level, you will get the existing token back. If you have an RW token and you ask the user to reauthorize at RWD level, you will get a new token back.

Recently there was a question on the mailing list about how to inform users of the new permission level. Ultimately the method you choose is up to you and the opportunities and information your application or service provides. Some applications would prefer to be proactive, whilst others can be reactive. Which your preferred approach below are a a few suggestions we have seen or heard other developers will do:

* On your first attempt to read direct messages that responds with an error, display a helpful message indicating the application cannot read the direct messages until the user has reauthorized.

* On their first use of your updated application or service, prompt them to reauthorize.

* If you know the email address of the users of your app send a message about the new permission and link to our blog post (http://blog.twitter.com/2011/05/mission-permission.html)

* Send a Tweet as the account that represents your application. This Tweet can let users know an update is available for the application to accomodate the new permission level on Twitter.

* Add a blog post on your application or services homepage about the new permission level and what it means for your applications.

* Prepare a support response or FAQ entry that you can give to users if they contact you saying they cannot access their direct messages anymore

In case you missed any of the previous emails or questions we've compiled an overview page and FAQ on our developer resources site:

    * https://dev.twitter.com/pages/application-permission-model

    * https://dev.twitter.com/pages/application-permission-model-faq

Best,

@themattharris

Developer Advocate, Twitter