Currently we can access 1on1 DM via Twitter API but not group conversations. If we forcibly set the group's conversation_id, Twitter API returns forbidden. Allow this.
ref
https://developer.twitter.com/en/docs/direct-messages/sending-and-receiving/api-reference/new-event

Tweet threads have become increasingly popular over the past few years. This API would enable developers to tap into the potential of threads by programmatically creating threads, as well as retrieving all Tweets in a thread.

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.

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".

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

Having access to an API for Twitter native polls would enable developers to create and schedule polls, as well as get back engagement data such as impressions, responses, Retweets of the poll, and their resulting responses, reach, and total engagement.

Currently there is no way to only return promoted tweets. With a "filter:promoted" filter option, it would be possible to only return promoted tweets combined with other search terms.

This feature would help researchers and increase ad transparency.

As a new developer, I want a lightweight way to make an API call within the documentation with little setup involved. I need to see and evaluate quickly what a request and response looks like for a specific endpoint.

Language consistency would be helpful.

• API Representation uses "favorites", but the current Twitter interface uses "likes".




• In the documentation for "Account Activity API" notes "likes", while in "Search Tweets" notes as "favorites".




• Perhaps not all of us are aware that "favorites" is a precedent of "likes".

Create endpoint for get "quote tweets" by other to Tweets authored by the user. Like endpoint statuses/retweetsofme.

It would be useful to be able to retrieve more than 100 results calling GET statuses/retweeters/ids
The current limitation doesn't make sense.

Twitter could build a more affordable version of the enterprise Engagement API, which would provide developers with Tweet metrics for owned Tweets.

Engagement data returned by the API includes number of Likes, Retweets, replies, impressions, and engagements (for example, number of link clicks). This API would enable developers to better understand their reach and impact on Twitter.

Twitter could include a list of approved Twitter libraries for different programming languages in the documentation. This would equip developers with robust resources and help them know which resources they can rely on to use the Twitter API.

Include message lifetime reach (unique impressions) and profile-level daily reach metrics for messages. This provides better insight into the number of individuals that saw a specific tweet or content associated with a profile/brand.

It appears that the user-auth rate limits in the labs API is shared among all users.
I could see however that app-auth limits are separate, so there is distinction between app-auth vs user-auth, just not working as expected

I would like the Twitter API to use OAuth 2.0 instead of OAuth 1.0. OAuth1.0a is fairly specific to the Twitter APIs at this point in time. It's complicated to implement, and there is a dwindling number of developer tools that support it. OAuth 2.0 is less complicated and easier to build into an app than OAuth 1.0.

It could be great to be able to use the "list:username/list-name" search parameter into the filtered stream endpoint, to watch tweets from a list of users rather than chaining "from:usernameX" parameters until the 10*512 chars are used.

Especially since the new endpoint will replace the current one that currently allows to watch up to 5k users (the "from:xxx OR " method will only allow to watch 250 to 400 users depending on the average username length ; that's more than 10x less than before).