Comment by wizofaus

That last suggestion (of returning 200 but with a message explaining that usage limit has been reached) seems odd to me - I'm not saying I haven't seen code that simply retries on any error but that could just as well include an error trying to parse the response and extract meaningful values from it. What I have observed is that client code often logs or relays HTTP status response codes (and 429 explicitly exists for this case) but rarely bothers doing the same for unexpected message content, which at best might be logged or conveyed to an end user as some sort of "failed to parse" exception. Surely a better option to avoid getting hammered is to return 429 after a 15-20 second delay?