There's been some grumbling in the past about the unreliability of really ludicrously long URLs sent to the API.

We've always considered this suboptimal, but the underlying technical constraints (http.sys + IIS + .NET 3.5) made fixing this a very arduous endeavor.

Well, ardor has been endured and the API should accept any reasonable construction now.

Be aware that once you go past 100 ids all bets are off as something will kill such requests. If its not the API itself, you'll probably get something unexpected back.

Also be aware that standard HTTP timeouts and the like apply, so really massive requests on expensive routes run the risk of Gateway Timeouts (not to mention whatever client side timeouts you may be imposing or have imposed upon you).

  • 2
    ++ pleasing customers is an admirable trait. ;-) Commented Jul 22, 2010 at 17:23

2 Answers 2


This has been unfixed. The API is back to its old tricks only accepting around about 30 ids.

  • umm... click the test case above. looks like it is un-unfixed. or de-unfixed. Commented Aug 3, 2010 at 23:23
  • Awh what a headache, that URL didn't work literally 5 minutes ago Commented Aug 3, 2010 at 23:29
  • 1
    Actually, click on it a few times, sometimes you get HTTP 400. Seems intermittent. Commented Aug 3, 2010 at 23:31
  • confirmed. and inconsistent is more annoying than just broken ;-) Commented Aug 3, 2010 at 23:41
  • we added a new server and this requires a manual step to make this change. url lengths are now back to "crazy long" Commented Aug 4, 2010 at 0:16
  • Thanks, this should help. My app is now failing Jon Skeet test miserably - requesting in batches of 30 :( Commented Aug 4, 2010 at 0:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .