Why don't we have the same kind of statuses/retweeters/ids endpoint but for likes, in order to get all the user ids who liked a particular tweet ?

Images in tweets should have their alt text available via API. Make it obvious. Here is where I would have expected to find it: https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/entities-object#media

We need a way to manage muted keywords, similar to the existing endpoints for muted users:

GET mutes/keywords/list
POST mutes/keywords/create
POST mutes/keywords/destroy

When I try to hide a Tweet in a thread that wasn’t started by the authenticating user, I get the response:

(
[title] => Forbidden
[type] => about:blank
[status] => 403
[detail] => Forbidden
)

I understand that this action should actually be forbidden, but the error in the API response doesn't tell me why the action is forbidden (which is that the authenticating user is trying to hide a Tweet in a thread that wasn't started by the authenticating user)

Really often, people on Twitter define a choice on their poll just to let people not concerned see the result. Why not providing a simple button to let anybody see the result without having to choose an answer ?

Add an API version of the popular "Who to follow" link seen at lower right on the home page: https://twitter.com/<...>/whotofollow .
(Currently it uses non-public APIs under the hood.)

Implementing a search bar solely for your timeline will save users from wasting time trying to remember tweets when they refresh the app. Instead of having to scroll down, search for the tweet with words that are constantly used in the atmosphere, and for those that may have forgotten to bookmark it immediately upon sight.

I would like to recommend building a conversations API that enables developers to track updates to full conversation threads. This API would retrieve the entire conversation that a Tweet is in, and return all Tweets and replies within a given thread. This API would enable developers to go from a Tweet of interest to all replies in the thread, without having to recursively search for Tweets with the correct "inreplytostatusid".

Can be interesting to split in two the type of medias in user profiles.
1/ Personal pictures of the user (where he is tagged)
2/ All the rest (gif, memes, etc.)
Currently it's a little bit messy when you want to check the medias of a user.

It's a pity to not be able to create a poll providing images on the same tweet. Why not adding it, like you did for retweet few years ago ?

The evolution of this week was really interesting, but I would go further and like Facebook, let the user decides WHO can see a tweet (everybody, only my followers, our only the mentioned users).

The user_timeline endpoint currently has a hard limit of only fetching the most recent 3,200 tweets. I understand this limit if the authenticated user is requesting for timeline tweets from another user. But what if the limit could be changed when the authenticated user is fetching tweets from his own timeline, e.g. the most recent 10,000 tweets or all? Other platforms such as Instagram allow you to fetch all of your media from your profile.

Thanks.

It's useful to have the date of last activity of a user. Before we could deduce it from the most recent tweet but now it's gone in v2 and it become really tricky to get this information.

If I want to filter for original tweets only I can use -is:retweet and -is:quote, but then I still receive tweets which are discussion replies. I can filter them out manually as a work around by checking for inreplytouserid values in the streams data fields, but having a is:reply entitiy operator would be very useful and save traffic and processing power on both sides.

As a developer working on a social analytics platform having a field in each Tweet that signals the calculated sentiment for Tweets would be very beneficial.

I currently have a Bayesian Classifier that performs this task but maintaining my training data to adapt to newer Tweets is a big overhead.

We can use Azure Cognitive Services APIs but there would be considerable costs processing data at scale.

It would be really helpful to have an analytics endpoint in which the entity was a media ID (in my case a video ID) and you could request engagement & video metrics aggregated at the video level, even if that video appeared across many different tweets. Right now this is possible through the Engagement API for video views only, but it would be great if it were available through the Ads API & included seconds/minutes viewed, percentile completions, call to action clicks, etc.

Surface is the first tweet in the hashtag, to know the founder of the hashtag, it is his right; and also there are those who use the hashtag for no purpose intended for topic of the hashtag (no objection to it), but you are tired to reach the news for which the hashtag was founded due to the large number of tweets outside the same topic.

The standard search API is somehow regarding screen name as part of text body and therefore is also searching in screen names. That can cause the search results to contain irrelevant tweets. For example, searching the word "nature" can return @human_nature's tweets whose text bodies don't contain the word "nature".

A similar issue applies to user mentions. For example, searching the word "nature" can return tweets which contain user mention @human_nature and don't contain the word "nature".

Please consider implementing an option which prevents the standard search API from searching in screen names and user mentions. Thanks.

Wildcards would be very nice to have in filtered streams: Customers want them, and there is no way to emulate it on our side.

When a query term contains a * character, * would match any character in a tweet, one or more time. When a query term contains a ? character, ? would match any character, exactly one time.

For example, Tw*ter would match Twitter, Tweeter, Twiter, Tweetter.