Posted: Apr 04, 2012 @ 01:02 PM             Msg. 1 of 5

Hi,

While testing some possible user actions we have found that we can get the API to return "Too many requests"

What kinds of API actions may trigger this and what rate or amount is considered too many?

What does the server or local API do in response to this condition?

What is required to clear the state?

It seems like we can still do new history requests and subscribe to new bar and tick streams after the error, but attempts to look-up previously returned options strike contracts via IOECClientPtr->Contracts->Item by symbol results in a null OECAPICOM::IContractPtr.

The state may have been entered by re-requesting IOECClientPtr->RequestContracts or IOECClientPtr->Subscribe. I haven't tracked that down yet.
Edited by jlanawalt on Apr 4, 2012 at 13:07:23

Posted: Apr 04, 2012 @ 03:35 PM             Msg. 2 of 5

Almost all API requests will cause that. Restriction is 5000 request per hour, but it can be changed in future.


Nothing, except sending the error message. Request will be ignored.


Not sending requests for some time (less than one hour)


Price-related requests goes to different server but it has same restriction and you will get the same error in case of very frequent requests.

---

Dmitriy Gorbachyov

Posted: Apr 04, 2012 @ 06:54 PM             Msg. 3 of 5

Thank you for that insight. Unless my code is doing something completely different than I am observing (possible, I'm still tracking) then it seems like I am hitting this limit much sooner than before 5000 of the same request.

After about 11 re-requests to subscribe and unsubscribe from about 160 ESM2 options strikes I hit the wall/error. The error continued to persist for most of the last hour as I would occasionally get a price update and then make a little progress requesting another strike.

At 5000/hr, shouldn't I see a refill at 83/min? At that rate it seems I shouldn't have to wait more than 2 min before I can get my 160 with no error, unless unsubscribe and subscribe both count, then 4 minutes. Not 40+.

Even if the limit is 1800 for some reason (the number I expect 11 requests of 160 each to generate) it seems I should recover at a rate of 30/min.

The longer it was from the initial error, the more that came in before the error appeared again, so it was "refilling", but it doesn't seem to be anywhere near 5000/hr / 83/min requests.

Posted: Apr 05, 2012 @ 02:56 PM             Msg. 4 of 5

API can send other requests, you can switch the API logging to more detailed to monitor subscriptions.

If you implement UI with OEC API you probably need to introduce some restrictions to reduce API resource usage, for example:
- Throttle price subscriptions/unsubscriptions or other API message flow by timer
- Use paging or other technique and subscribe only to visible items

---

Dmitriy Gorbachyov

Posted: Jun 12, 2012 @ 07:40 PM             Msg. 5 of 5

We are using paging to subscribe only to visible items. I haven't sorted out how to cleanly throttle API messages with timers.

I still question the refill rate. It does not appear to be anywhere near a steady 5000/hour. I read the other thread where you explain that an unsubscribe and a subscribe both count, so I get that if I unsubscribe and resubscribe to 33 new items, that's 66 against my limit.

I messed with the program, paging up and down until I hit the subscription limit for quotes/price data. Then I waited 10 minutes and tried again and still hit the subscription limit. Either I'm grossly miscounting, or the "refill" I expected of 830 requests did not happen.

Is the "refill" instantaneous moment by moment or is it recalculated only occasionally?