I was wondering if the scenario of a server based app that lives in a hosted environment, where a single IP can be shared by many web sites.

As I understand the rate-limit as it stands, every site on the shared host IP, regardless of api key, will be sharing the same rate-limit of 10,000 per site per day.

I can see two possible ways to remedy this problem, if in fact it does exist:

  1. use the referrer authority, if it exists
  2. remove the ip from the equation and limit per key


We have an answer but let me draw a silly picture to make the story perfectly clear.

George decides to switch over to asp/c# so he can use the fantabulous soapi library and buys a shrared hosting account on discountasp.net.

By the luck of the draw, his domain, with his exponentially growing list of rate-limit gobbling apps, gets placed on the same shared host that my slowly growing list of request hungry apps are living on.

My cron kicks off in the middle of the day and fails.

Why? because although George is using a different API key, we share the same IP, so when I kick off expecting to get a good 5000 requests in over the next 3 or 4 hours, they are already used up.

The explained solution is to get a rate-limit increase or other allowance.

But with the current setup, there is still no segregation between the request volume of the two completely unrelated keys. So any rate increase is still shared by George and I and if the count comes up short and one of our apps breaks, who to complain to and with what metrics?

The reason this seems to be an issue to me is that there are subjective conditions that must be met to warrant any kind of rate-limit adjustment.

So I guess we will just have to keep an eye on our rate-limits and be vigilant for inadvertent usurpation and revisit the issue then.

Seems to me that using the TDL and IP of the request source, if it is available, would be one way to eliminate this problem. I have not explored the technical details of this but it might be worth exploring.

  • I'm not seeing the picture... where is the badly-drawn silly freehand cartoon illustration promised?
    – SamB
    Commented May 1, 2011 at 1:49

2 Answers 2


We've indicated in the past that the per-day limit for a key can be increased if need is demonstrated.

We will not be increasing a key limit based on "anticipated need," though. It must be a clear and present one. There are also somewhat different rules for managing "elevated keys."

  • 1
    Do you recognize the issue that I am describing? Your answer seems to indicate that you are reading my question as a rate-limit increase when it in fact is describing a scenario where a rate-limit will be consumed by multiple and unrelated apps/websites. Commented Jul 19, 2010 at 14:56
  • @code - yes, I understand. It just so happens that the same solution covers both problems, as one is a slight variation (one->one app->IP, versus many->one app->IP) on the other. Commented Jul 19, 2010 at 15:49
  • @code - yeah, that's the short of it. If for whatever reason your quota is insufficient contact us, and explain the case. We'll take it from there, as there is not (nor will there likely ever be) an automatic process for dealing with key usage oddities. Commented Jul 19, 2010 at 16:20
  • 2
    oops - deleted the comment you replied to. in any case thanks for the clarification. in the interest of being clear - i am describing, perhaps not too clearly, a scenario where Tom and Harry both have apps that live on discountasp.net's web001AXD.discountasp.net host and Tom is eating all of Harry's requests, which if discerned by IP only will be indistinguishable and any rate-limit increase for that IP will potentially be eaten by Harry as well, starving Tom out. A far-edge case, to be certain, but possible. Commented Jul 19, 2010 at 16:26

I completely understand and share your concern. (I have no intention of switching to C#, though.)

My concern is for my own apps which share a server. StackMobile, StackList, StackCenter, StackImage, Stack2XML, and StackMail all share a server.

None of them are getting enough traffic for this to be a concern, though.

  • 1
    patience grasshopper - you will be buying extra bandwidth before you know it. Commented Jul 20, 2010 at 6:38
  • @code: Nope. My plan allows for unlimited bandwidth. I'll have to buy a dedicated server instead if stuff goes out of control. Commented Jul 20, 2010 at 15:43

You must log in to answer this question.

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