New direct_messages/events/list request doesn't contain screen names

[iagdotme]

I am working on migrating from the old way of retrieving direct messages to using the new https://api.twitter.com/1.1/direct_messages/events/list.json request (since the old one is being shut down in June)

With the old https://api.twitter.com/1.1/direct_messages.json request, it gave the screen names of the person who sent the direct message. With https://api.twitter.com/1.1/direct_messages/events/list.json it gives very limited information, and only the ID of the user. That means I’d have to do another call on the Twitter API.

Am I missing something here or was this a deliberate omiossion from the new Direct Message API?

[andypiper]

This is not a deliberate omission but yes it is a change in behaviour. Given all twitter accounts do have unique identities what is the issue here?

[iagdotme]

Thanks, @andypiper

Well I just wanted to display the direct messages with their authors with the data from one request. With the old method, I could get the screen name and the message in one go. With the new system (unless I am missing something), as well as making the events/list.json request, I’ll need to cycle through all the IDs and request the screen name.

[collinsauve]

I’d like to second this request to include the screen name in the response. The lack of this means that consumers of the API have to maintain mappings of id->screenname, and make additional calls to the API to retrieve this. This seems like an unnecessary burden to place on the consumer.

[collinsauve]

Any way we can get this before the old APIs are removed? (August 16th, 2018)

Additionally: without going into too much detail as to how we deal with rate limits, I’d like to note that adding the requirement that we deal with the rate limits around users/lookup.json while working within the rate limits of the DM api does add a non-trivial amount of complexity.

[jcbl]

Just seconding this and adding that, unlike the old DM endpoints which were pretty close to realtime, this new endpoint introduces a fair amount of lag, which is only compounded by the need to add an additional API call.

While I understand that a developer could cache the user id > username mapping, it’s an additional ask on top of an complicated transition where we’re already being asked to degrade (due to the new non-realtime nature of the new service) functionality that relies on this set of endpoints.

[collinsauve]

The deadline for switching keeps getting closer and closer without an answer to my question (can we get a fix before the deadline). We need better communication from Twitter staff about this issue and their plans to address it so that we can make decisions on how we are going to rebuild our integrations.

[andypiper]

There are no plans to change the implementation of the new Direct Message endpoints at this time.

[collinsauve]

Thank you @andypiper.

[LeBraat]