Invalid or inaccessible "in_reply_status_id" does not fault but is treated as null; bug or feature?

[vintrax]

Hi,

I have noticed unexpected behavior when trying to reply to a Tweet using the REST API.

1. Whenever I use the POST statuses/update call containing an invalid in_reply_to_status_id value, this property seems to be treated as null. As a result, the reply is treated as a “regular” @mention message. I would expect some sort of error.

2. The same applies to whenever an inaccessible/restricted in_reply_to_status_id value is used, such as the id_str property of a deleted or protected Tweet which a user does not has access to. In this case, I would expect an error, such as the 179 error:

“Sorry, you are not authorized to see this status”
"Corresponds with HTTP 403 — thrown when a Tweet cannot be viewed by the authenticating user, usually due to the tweet’s author having protected their tweets."
https://dev.twitter.com/overview/api/response-codes

Instead, this reply is treated as a “regular” @mention message as well.

I would like to know if this designed behavior and how to validate the in_reply_status_id property? The validation of the in_reply_to_status_id property does not seem to be automatically done with the POST statuses/update call, is that correct?

How would you advise to validate this value based on validity and accessibility?
By using an additional API call such as the GET statuses/show/:id? I personally would find an additional call a waste, among others considering the API rate limit.

Would love to hear some feedback as I consider the validation of the “in_reply_to_status_id” property a must in order to prevent unexpected, functional behavior.
Obviously the value of this property, based on the original id_str property should never be corrupted, but a use case could be whenever a user A attempts to reply to a public Tweet of user B, while around that same time, that same Tweet is made protected. The reply of user A then makes no sense as a regular message to user B.

Thanks!

[joncipriano]

Hi @vintrax, thanks for the detailed analysis and also for the feedback. I can confirm that this is the behavior. I am not the designer of the specific endpoint, but I would make the assumption that in most cases the user or developer would like to see the Tweet published instead of the action being blocked entirely.

The suggested approach for situations like this are exactly what you touched upon. A request to GET statuses/show before publishing the Tweet will verify if the Tweet exists. This endpoint has a rate limit of 180 / 15 min. You are already using a user context and I don’t think a user would be reply Tweeting more than 180 times every 15 min, so the limit is sufficient.

If your use case involves some sort of batch re-tweeting then GET statuses/lookup allows you to request Tweet objects for up to 100 Tweets in a single request. This endpoint has the same rate limit as statuses/show, so you could validate 18,000 Tweets within a 15 min window.

The above approach is also similar to how you would verify user accounts with GET users/show and GET users/lookup before Tweeting at them.

[vintrax]

Hi @joncipriano,

Thanks for sharing your thoughts about that the behavior most likely is the designed behavior and all of your other feedback.

Regarding the rate limit; this might indeed be sufficient for one user for one account. However, if multiple users share the same account - and thus share the same access token to which the API rate limit applies -, the rate limit might be (easily) hit. This situation, for example, applies to a generic customer support account, maintained by multiple users who work simultaneously.

Given a similar use case for a popular account, I easily and repeatedly exceed that rate limit on a daily basis. Perhaps the Partner Program offers a less strict rate limit but I have been told that the Partner Program does not permit certain use cases such as the self-storage of Tweets - which for instance, will be huge performance loss within that same use case. Certainly do correct me when I seem off about that remark on the Partner Program. Perhaps the conditions have changed over time or I have not been informed correctly.

Nevertheless, considered that the current design and “restrictions” are just the way things are, wouldn’t it be a great idea to extend the POST statuses/update call with an additional parameter which will block the entire action with an error response whenever the reply could not be made for some reason? Such as an “alway_update” parameter which defaults to true, but where developers such as myself are able to be set it to false in order to restrict failed “reply” attempts?

From an architectural point of view, I find it quite odd that whenever the POST statuses/update endpoint is used to send a reply, it might result into another action on a functional level (in this case, composing a new message to the user instead). As a developer, I would love to be in control of that choice. Or at least, would love to be informed about it at forehand by mentioning in your documentation.

I would love to hear your thoughts.

[joncipriano]

Gotcha, what you are saying makes sense. There are quite a few existing CRM applications that do what you describe and work well in the current state of the API (example: Lithium). I will assume you are building an application for multiple Twitter accounts to login to, each having multiple users who will Tweet through those accounts. As the owner of the application you will have to be aware (as you probably already are) that you don’t have control over the rate limits of user accounts logging in to your app.

If a CRM Twitter account is going to require more than 180 API calls in a 15 min window, the company behind it is going to be large or have a significant Twitter presence (example: @ATTCares). The Twitter account will very likely have elevated access or be verified (blue badge) with higher rate limits. In other words, if a company is going to be conducting very large amounts of CRM actions on Twitter they will most likely be working with us to ensure certain switches are flipped for them, in addition to integrating with your app. This is done because a CRM type tool could easily be used maliciously and that needs to be prevented as best it can.

I recognize I’m not answering your question yet, but thought it should be explained how CRM is conducted currently. To address your latest points:

1. I can’t comment on partner program policies, since it is not my area, but you can find more information at partners.twitter.com. You can also use this form to inquire about policies and rate limits. I can say the first thing that is considered is if your app conforms to the Developer Agreement & Policy. Some devs ignore that and I can’t stress enough how important it is if you are pursuing a partnership.

2. Your suggestion about an “alway_update” parameter is great idea and is feedback I can provide the eng team here. However, they have certain priorities and I would not guarantee any actions would be taken immediately.

3. In regards to POST statuses/update documentation- absolutely, this is something that can be added and is the least we can do. The docs are a hot subject here as we are looking to make significant improvements this year.

Tracked internally as PREL-14360.

[vintrax]

Hi @joncipriano,

Thanks for your comprehensive feedback and for passing on some ideas to the team, it’s greatly appreciated!

Your assumption about the application I am working on is spot on. Some of the Twitter accounts are verified (blue badge), but certainly not all. Do I understand correctly that verified accounts are appointed a higher rate limit? I do not seem to trace that back in the FAQ. This is good to know, although I understand that the verification process is determined solely by you - which is fine.

Nevertheless, I certainly will do some new inquiries about the Partner Program.
Thanks your feedback about that too.

[andypiper]

Hi @vintrax - as Jon says, some accounts have elevated access with higher rate limits. This includes verified user accounts. I’m afraid we don’t publish the specific numbers for these. Thanks for your very interesting questions and feedback!

[moodboostai]

Hi! just a silly question, im using python tweepy, how I avoid to "in_reply_status_id” treated as null, I mean, how I call my function to if the example that ventral gave : inaccessible/restricted in_reply_to_status_id don’t tweet mention the user just ignore it, how I validate that, thank you

[LeBraat]

Was your question not answered in this topic? I think @joncipriano might have addressed this here:

I can confirm that this is the behavior.