Reply to tweet does not work anymore since a few days

api

#1

Hello,

A few days ago, I received a post telling me that replies to tweets was not working https://tweetinvi.codeplex.com/discussions/645063.
At first I thought the user was not using the library correctl as few days ago the library was working as expected.

Today, I received the same error as he still encounters.

The problem is that as written in the documentation for in_reply_to_status_id

This parameter will be ignored unless the author of the tweet this parameter references is mentioned within the status text. Therefore, you must include @username, where username is the author of the referenced tweet, within the update.

Now this rule has never been enforced in the past, Tweetinvi has successfully passed the integration tests of Tweet replies for years. And we all know that no one can rely on the documentation to know what to expect from the twitter rest api (test and failure is the only way).

And to be honest this rule does not make any sense at all. When a tweet is published with a valid in_reply_to_status_id, you should ensure that the @username is set up on your side. Because otherwise it forces user to make 2 request to do a single action.

https://api.twitter.com/1.1/statuses/show.json to get the creator ScreenName

In the past we were able to only call https://api.twitter.com/1.1/statuses/update.json once and this worked as expected. I hope this is temporary because this does not make sense, it costs Rate Limits which are already too restricted and in addition it forces your platform (api.twitter.com) to reply to even more requests.

The error is not unique to the twitter library Tweetinvi but can also be reproduced on apigee and other libraries.

So please could you confirm what is to be expected. Should we follow the documentation in for this parameter or should we expect the REST API to behave as it always did for the last 3 years.

Thanks,
Linvi


#2

Where is the support team? Up!


#3

Hello, it has been 10 days now. Would someone in the team please reply to the question? Up!


#5

12 days and counting…


#6

Apologies, I’m trying to find out whether anything has changed here.


#7

Yes, thank you Andy, I am just trying to get the attention of another developer who might know about this.


#8

17 days and counting! Any developer apart @andypiper could reply please?


#9

I would recommend that you follow the documented behaviour. Even if the undocumented behaviour returns there is no guarantee it will continue working since it is not a documented feature backed with a deprecation policy.


#10

I did talk to the team internally and we did not believe that there was any change. However, you’ve said you saw a different behaviour, and I didn’t want to just discount that since you’d gone into a good amount of detail. I really can’t confirm myself, as I’m not familiar enough. I would expect the documented behaviour to be the one to follow.


#11

First of all thank you to both of you for taking some time to reply. Thank you andy for taking time to check with the team.

I will follow the documentation on this one, but please you need to make sure that the team is aware that the documentation is very out of date and not working. I have been developing a C# wrapper library for Twitter for the last 3 years and in no way, we as developers can rely at 100% on the documentation. The simple reason is that sometimes, what is referenced just doesn’t work, or that parameters are missing or that the description is just wrong. For example recently I discovered it was possible to add a Media_Id parameter to an endpoint, the documentation did not reference this parameter (I will try to find which endpoint if you are interested).

So I would be more than happy to follow the documentation but we need one way more accurate than the current one. I use API Changelog to track the changes of the doc but they are always very minor.

Concerning the reply_to_id I really think that the team should consider getting back to the previous state of the library where @screen_name was not required in the text.

Anyway, thank you very much for your answer.

Cheers,
Linvi