coderjoe.7538:

I notice that neither the V1 or the V2 APIs list rate limit requirements.

The responses don’t contain caching headers or etags to assist in limiting my requests to appropriate lengths either. Am I to assume there are no rate limit requirements for users of the API?

If not where can I go to get the appropriate request rate limits for each of the API endpoints?

Thanks in advance!

AysonCurrax.3254:

I would also like to know how many parallel request i can hammer the endpoints with, since i d like to prevent being IP blocked for possible misinterpretation as a DDOS attack. As of now i am sending up to 4 parallel requests to the v1/item_details api, which takes a fairly long time as is, so if possible i would send several more simultaneously. The Question is: what is too much, and what isnt?

darthmaim.6017:

v1/item_details

Take the v2/items endpoint and it will be much faster, because you can request multiple items at once.

smiley.1438:

See also: https://forum-en.guildwars2.com/forum/community/api/How-frequently-is-it-OK-to-access-the-API

coderjoe.7538:

Thanks for the updates everybody. I’m not sure why my forumkittendidn’t pick up these duplicate topics all over the place. I must fail at searching.

That said, I really wish they’d publish an official stance on the wiki or even better provide cache hints or etags so I can more accurately expire my caches.

Pat Cavit.9234:

If we implement rate limiting we’ll announce it, until then have fun.

AysonCurrax.3254:

v1/item_details

Take the v2/items endpoint and it will be much faster, because you can request multiple items at once.

I know that. I was just asking for reference. :P

coderjoe.7538:

If we implement rate limiting we’ll announce it, until then have fun.

Thanks Pat!

Hopefully future rate-limit changes should be a non-issue for me.

I recently implemented a policy of setting up a caching proxy sitting between my servers and any 3rd parties which should be limiting my requests based on their endpoints and how often I think the’re likely to be updated (or based on their published rate limiting requests).

As an aside I’m so glad systems like this are so easy to set up these days.