What steps will reproduce the problem? 1. Execute the /expand, /info and /stats methods using a non-existent hash as the argument (like 1234THISISFAKE4321). 2. Compare the results.

What is the expected output? What do you see instead? I expected the error reporting to be consistent about these calls, as they all deal with single or batch requests, and they all operate on already-shortened URLs.

/info Behaves in what may be the most logical way. If the method itself executes without error (barring invalid results), no error is reported in the top-level error keys. If the requested hash/url doesn't exist, that error is reported within the relevant key (the submitted hash/url) using the familiar error keys. That seems the most logical to me because it clearly shows two possible levels of errors: API/method and then method arguments.

/expand Reports an error at the top level indicating the presence of an error to be found in one of the result sets (unless there is no error). This isn't crazy because the code specifically indicates that an error in the contained batch is present. The crazy part to me is the inconsistency with /info.

/stats Doesn't seem to report any errors at all, which to me seems just plain wrong. If an invalid hash/url is provided, I would expect a relevant error to be returned.

What version of the product are you using? On what operating system? 2.1 - any

this is now fixed with the release of v3 bit.ly api