Reputation: 6579
I am quite new to using public API's and I came across a problem that I am not quite sure how to approach. The bottom line is that I have signups on google forms and I will get about 100-150 players signing up on my game nights. When this happens, I need to go through them and make sure that all 150 of them owns the game and has at least 50 hours played in the game, this is my measure against the growing number of smurf accounts I have been getting.
As such I have written some code on my server that will look at the Steam ID that is provided and then get the games they own along with number of hours they play in. With this I identify the game in question and then I simply give a pass or fail.
While this is all nice and dandy, I am getting worried about the number of requests I am sending over and if I should be handling this differently. Right now if I have 150 players, I will send 150 requests to steam and that just doesn't seem like the right thing to do.
Looking through their API, I was not able to locate any kind of method that will return me games owned by range of players. As such, the only thing I can do is what I have described above.
My question is this:
When using public API's such as Steam's api, is it ok to use the approach I have above? Would sending such high number of requests get me blacked listed as a potential spammer, or what would that number be before I should start getting worried?
Upvotes: 0
Views: 1370
Reputation: 1491
Yes, it is absolutely ok to use your approach.
From the Steam Web API Terms of Use:
You are limited to one hundred thousand (100,000) calls to the Steam Web API per day.
When consuming public APIs (not only Steam's), always have a lookout for the terms of use.
If you reach that number you could start getting worried. Then, the worst thing that could happen is that your requests will not be satisfied anymore and it's likely that your API key will be revoked (that's one of the reasons it is here for).
There are speculations that the Web API has further restrictions:
WARNING: The community XML data is deprecated. We recommend using the web APIs whenever possible.
It is very probable that Community Data has a far lower rate limit as it is recommended to use the Web API instead.
Notes:
Whilst developing completionist.me I never hit any of those restrictions. It was at 30,000/day once and not one unsatisfied request occurred (at least not caused by rate limiting).
If you want to be sure make use of job queues for throttling on the client side to be in control of the request rate and retry failed jobs (API requests) after a period of time.
Given that an API is well implemented you would be presented a HTTP 429 - Too Many Requests before getting into any "trouble". As far as I know this is not the case with Steam's Web API though. It silently fails with HTTP 403 instead if an error occured (most of the time).
Upvotes: 1
Reputation: 2123
Sending 150 API calls per day, in the context of a major provider like Steam, is nothing. They will start throttling your requests if your service gets to chatty, but that cutoff for Steam should be approximately one request per second.
If the API provides a batch call or a query call, it is good practice to use it. For example, GetPlayerSummaries should allow you to supply multiple steamids in a single call. For getting detailed information, as far as I am aware, Steam does not provide a batch API, making what you are doing the proper way to go about things.
(Tangential comment: you may want to consider whether this is the best way to accomplish your goals, or whether a change to the game design/matchmaking/etc. to make smurf accounts less valuable might be more effective in attacking the problem at its root.)
Upvotes: 0