Twitter currently offers three levels of app permissions: (1) read only; (2) read and write; (3) read, write and access Direct Messages. These options are not granular enough for some developers, and developers would like more options to choose from.

For example, an app’s “write” permission could be segmented into more granular options: (1) write access to a user’s profile; (2) write access to a user’s network (follow/unfollow, mute, block, list modification); (3) write access to a user’s timeline, including the permission to Tweet, Retweet, or like a post.

Another example includes Sign In With Twitter: there could be an option to implement the sign in flow with “read” access only.

Here’s one example of a past forum post with a related request: https://twittercommunity.com/t/suggestion-more-granular-read-write-app-permissions/121810

We have built a social media management app that allows our customers to also view insights for their social accounts and posts.

Every midnight we refresh insights for all posts published via our app in the past 7 days.

For Twitter, we're only recording the number of favorites and retweets (returned by the /tweets endpoint), but we would like to gather more metrics, such as impressions, # of replies and video views.

The current rate limit is 15 requests / 15 minutes and 50 Tweets / request.

This basically means we can gather metrics for only 15 customers at a time (up to 50 Tweets per customer), unless we add a 15 minutes wait time between jobs.

This would work if the rate limit was at the user level instead of the app level, similar to elevated POST limit.

I know that the enterprise API is another solution, but we simply cannot afford that at the moment.

We use the Engagement APIs extensively in our product. We currently have to use a combination of the /totals endpoint with the /28hour and /historical endpoints to get "urlclicks." Right now, the new Metrics labs endpoint provides all the great metrics that our customers want in a single endpoint except for "urlclicks."

Without "urlclicks" it would be difficult to transition off of any of the Engagement APIs to a new Tweet Metrics endpoint. If this new endpoint had "urlclicks" we could replace all of our Engagement API usage pretty quickly and have better, more accurate data for our customers.