I would interpret section 2 of the Developer Agreement (specifically the section on reverse engineering) to cover the use of undocumented / non-public API endpoints.
dekisu
#12
Even if the developer agreement wasn’t there, the limitation is in the API endpoints (like andypiper said) and there’s nothing we can do about that other than waiting very patiently.
(Also, general reminder that twitter is relatively unique in this level of openness, with an extensive, well documented and public API. And most competing services in the group conversation area have awful closed protocols. Some of them even decided to get rid of the “open” way to access it. So, if anything, I’m thankful that this is a “not yet”)
2 Likes
ePirat
#13
Would this section also affect reverse engineering for security research? From my experience Twitter accepts reports of security problems even if the affected endpoint is a private one, without consequences for the researcher. (It might be good to clarify this somewhere as I wasn’t sure about it, so when I reported my issue I even made a new Twitter account just for this purpouse, as the report form requires to enter one)
Our application allows financial services firms to utilize Twitter for business purposes. The retrieval and ability to retain communications is a requirement of government regulating agencies such as FINRA/SEC.
I just wanted to throw another nod for this data to be available via API has our financial services firms may not allow their financial professionals to utilize direct messaging entirely since group messaging is so tightly integrated with direct messaging.
Thanks for listening.
We hear ya - we just do not have any news right now about plans for rolling this out as an API for more widespread use. Thanks for the input!
gnownad
#16
Like @JamRobWomm, we have large Enterprise customers who are regulated under various agencies that they have to reply to all questions asked of them (specifically healthcare and financial industries). If we’re not able to get visibility of group DMs this is an area of risk.
Would you be able to work with Twitter certified partners on this? We’d love to talk.
Thanks!
1 Like
@andypiper Hey, it’s been a while since the last message in this thread so I thought I’d ask again.
Any news on Group DM support being made part of the public API?
Thank you.
1 Like
No, I’m afraid this is not something that we’ve currently prioritised - finishing up testing on the removal of the 140 char limit for DMs, but nothing to share on group DM at this time.
Bummer, but thanks for getting back so quickly!
It has been over a year now. Is there any timeline for this?
This is not currently on our priority list for enabling as a public API due to some of the complexities but it is a known request and remains on the list to evaluate.
Any updates on this? Seems odd that it’s not there.
No updates or changes to announce - we’re focused on what we can enable using Twitter Kit in Fabric at present, as well as the forthcoming changes to Tweet objects that we announced a while back.
Access to group DMs is a central aspect of an application I stared working on recently to allow viewing DMs similar to an instant messenger. Only having access to single-recipient DMs is very constraining for that.
Could you elaborate a bit on what makes it a complex issue to expose as a public REST API?
Hey, back when I asked for group DM support I was building a prototype that was supposed to make use of twitter’s wonderful social graph and run on top of DMs and group DMs.
Sadly I think there won’t be any Group DM support in the API, at least not in a capacity that you can rely on now. I would recommend relying on another group messaging API. Should Twitter release a Group DM API it shouldn’t be much effort to add support for that.
Well, largely the point of my application was that it would not require users to register and rely on yet another separate service and instead allow them to reuse their twitter accounts and services.
Yup, that’s also why we initially built our prototype on Twitter.
Absolutely. Group DMs use a significantly different model to the previous format, so for a start it is there is effort required to document and describe. Secondly, we haven’t done any work around anticipating additional load and capacity needs driven from other clients on those endpoints. Thirdly, opening up any new API endpoints can sometimes lead to unforeseen behaviours if they are called in unexpected ways, which we’d need to more thoroughly test and account for. Finally, as I mentioned previously, we need to prioritise; the majority of what you will have seen around changes to the developer platform in the past year has been focused on Fabric, and embedded timelines and Tweets - so we can’t just “flip a switch” to open up an endpoint, much as it might seem that way.
I totally appreciate that this is disappointing if this is a feature you’re looking for, but I’m not currently aware of a timeline for enabling this.
The existing DM APIs have not changed and will continue to work for one-to-one DM conversations.
1 Like
I see. Thank you for your response. I suppose I’ll focus on one-to-one chat for now and hope that groups will make it into the API some time.
1 Like