Sporadic OAuthException Errors when attempting to retrieve DMs: error 401 code 89

restapi
oauth
directmessages
error-codes
api

#1

Hello, our application is having issues with the direct_messages/show endpoint. Our users are sometimes high frequency DMers and we call this endpoint every time they send a new DM (to retrieve the DM just sent).

For the past month, this call would have periods where they would always fail, returning the following exception:

401:Authentication credentials (https://dev.twitter.com/pages/auth) were missing or incorrect. Ensure that you have set valid consumer key/secret, access token/secret, and the system clock is in sync.
message - Invalid or expired token.
code - 89

For example, a user would be able to DM throughout the day, but sometime mid afternoon the direct_messages/show endpoint would start to fail with the above exception (but DM’s could still successfully post using this endpoint: direct_messages/new).

The error has appeared sporadically, happening for a period of days, then not appearing for a week for any customer, then appearing again for the past month. Now, however, we have stopped receiving those errors, even though we have not changed our codebase.

We were wondering why users are receiving this error? Even when the user receives this error, they are able to use the same access token to post DM’s with no problem.


#2

You mentioned that these are high frequency DM users, is there a chance this is being rate limited? That is not the error code I would expect in that case, but I wanted to ask up front


#3

It is possible, but these users are only sending on the order of dozens of dms a day (and therefore calling the endpoint in question maybe a few dozen times over the course of a day). Would that trigger a rate limit?


#4

Right ok - so probably unlikely. Another brief idea then is that it might have been a routing issue on our side, where some of the requests were hitting a data center with out-of-sync credentials for a brief period of time. Difficult to pin down without more detailed logging etc.


#5

Hmm That is interesting, is there anything on our end that we could provide that could help? In addition, some of these users were based internationally… Do you think that may have caused an issue?