Are there other error conditions that are similarly ganged up into 401? Or are these two the complete list? Are there other codes that have similarly ganged up error conditions that can only be distinguished by the response text?

Are the expected responses (not just the codes) for different conditions documented somewhere?

Also, off topic:
Any news on when we can expect the new oAuth with username/password flow to make its way into the API? If you can't let me know, or you don't know, I understand, but it would be good to hear whatever the case.


On Dec 29, 2009, at 9:45 AM, Raffi Krikorian wrote:

hi eric.

yup - you've hit it right on the head. one of the main initiatives in us starting to version our API is so that we can really consolidate and make our error codes consistent. unfortunately, for legacy compatibility reasons, we can't change the second case to have a 402 error and we will have to keep it as a 401.

what you could do is parse the response that comes back in the 401, however. in the case that your password is wrong, the error should be

"Could not authenticate you."

for basic auth and OAuth. the second case has an error of

"Not authorized"

On Mon, Dec 28, 2009 at 3:38 PM, Eric Marcoullier @ Gnip < > wrote:
We're trying to build some logic into our data collector and we've
been fighting with an issue for a while involving the 401
"Unauthorized" error code.

There are two instances where I can get this response

1) Bad credentials.  I try to log in with an invalid username or
2) I don't have access to a specific user's private account.

The former can be a real problem for a user.  I changed my password a
few weeks ago and forgot that I was using it for whitelisted REST API
access.  Querying three times in rapid succession with a bad password
causes a temporary lockdown of a user's account.  I was querying once
per second and locked the account for a five days. This is an account-
level issue and the proper way to deal with this from our perspective
is to immediately sleep the poller for 30 minutes and send an alert
about bad credentials.

This is completely different than if someone I'm following has taken
their account private.  In this case, sleeping for 30 minutes (or any
amount of time, really) is overkill.  Unless I'm querying for a single
person over and over, there's no reason to pause before moving onto
the next rule that I'm querying for.

Unfortunately, we have no way to disambiguate between the two 401s and
we're forced to either lock someone's account (ignoring 401s) or
severely reduce their polling efficiency (acting on 401s).

Best case would be to break these two error conditions out into
separate error codes.  Perhaps a 401 for bad credentials and a 402 for
lack of authorization for a specific piece of content.

Please let know if I've overlooked something that would help me
disambiguate the use cases in the current system.


Raffi Krikorian
Twitter Platform Team

Reply via email to