Agreed. If the API is going to overload an error code, Twitter needs to enumerate the error details and provide those details in a consistent machine readable form.
On May 25, 1:52 am, akaii <chibiak...@gmail.com> wrote: > There seem to be a variety of possible causes for getting an 403 error > in responses to a calling statuses/update... you could be duplicating > a tweet or hitting the update limit for an hour or for the day. > > How can you tell which one these errors actually occurred? > > The only 2 ways I can think of is to try and parse the error message, > or to follow up the request with a query about whether you've hit any > limits. > > The problem with checking the error message is that: > 1) It's fragile. If the twitter dev team decides to change the error > msg, the solution breaks. > 2) I'd have to know the error message first... and the specific error > messages for hitting the update limit don't seem to be documented > anywhere that I can see. Not in the wiki for sure. Which means that > I'd have to hit the limit to find out directly what the messages > are... not exactly practical, especially for the 1000 per day limit. > It would take me a minimum of 7 hours to hit that limit, since I'd get > capped by the hourly limit first. > > The problem with a follow-up request is that: > I can't seem to find a way to get current remaining tweets available > to the user before hitting the status update limit in the api. > > There's one for rate limiting: > account/rate_limit_status > > But where's the corresponding api for the status update limits? > > What should I do about this? Is there some third, better way to find > out which specific error resulted from the update attempt?
