Dr. McKay

Yes, that's the best (and only) way to do it.

You need an API key if you want to use the WebAPI. Based on your error message I assume that you're using steam-tradeoffer-manager, which does need an API key and consequently won't work with limited accounts. So yes, you'll need to spend $5 per bot.

Your own account? Or someone else's account?

If you want games someone else owns, there's a WebAPI method for that.

I don't know an awful lot about CS:GO, but I know that you can't inspect any tools. I don't know if there are any skins that can't be inspected.

https://httpstatuses.com/500

500 just means Steam is broken and you'll have to try again later. There isn't anything you can do.

1. Calling login() again with your username and password is guaranteed to renew your session (unless Steam is having problems). The oAuthLogin method is supposed to do this, but I believe it doesn't work 100% as expected.

2. There isn't any event. Currently you just have to check loggedIn every so often. The next update will most likely add such an event.

You can't inspect stickers.

Just pass true for that argument, and in the callback the items will have an actions array defined and populated with the inspect link (and any other applicable actions).

I just thought of a potential issue with using just the trade URL. Presently you have to construct an offer using a SteamID explicitly. Getting the ID from the URL opens sloppy implementations to the potential for users to send offers to other users.

For example, a typical implementation currently has a user sign in through Steam's OpenID, then prompts the user for their trade URL. Both of these are sent to the bot. The offer is created using the authenticated SteamID, and the token is extracted from the URL. If the trade URL isn't for that user's account, the offer just fails.

With the proposed new API, a user could enter someone else's trade URL. If the implementation doesn't check offer.partner, then unrelated users could receive unsolicited offers.

Of course, we could add a note to the documentation to check offer.partner when you use a trade URL, but I don't really like the loss of the built-in safeguard.

The way I generally do it is set up a bot in node.js using steam-tradeoffer-manager, and create a Web server in that bot which accepts commands to send trade offers. Then use curl in php to command the bot to send an offer.

I believe there are php libraries for interacting with Steam, but I don't personally think php is well suited for that task.

Yes, that will work fine.

Note that on Windows, the sentry (ssfn) file that the client uses is hidden. The visible one is a decoy.

The sentry file used by the client is named in config/config.vdf (if I remember correctly).

You can already create a TradeOfferManager for separate accounts within the same application.

How about support for multiple accounts?

I don't understand.

Here's an idea. Three options for createOffer():

1. manager.createOffer(steamID); // create an offer without a token. you can set it later
2. manager.createOffer(steamID, token); // create an offer with a token
3. manager.createOffer(tradeURL); // automatically extract the SteamID and token from the trade URL

Moved to general.

I'm not sure what the limit is, to be honest. I believe that if you keep it to around 0.5 req/sec you should be good.

About the sessions, how about an internal refresher? By default it would refresh cookies for example every hour but an option for the user to set it to whatever.

I've thought of that, but cookies can come from any source. For example, node-steam-user or node-steamcommunity, but there are also third-party sources. Really the refreshing should be done by your app.

Would it be possible to not have to worry about sessions expiring?

That's rather difficult, as Steam just kills sessions whenever it feels like it.

My wish list:

 

1. Promise-based API

2. If you're moving token and message into setters, it'd be nice to be able to specify them when the trade offer is created instead of having to make more method calls.

3. The ability to determine if an item already exists in a pending trade (not sure if this is possible)

 

 

That's all I have right this second, but I may have more later.

#1 is possible, although not likely to happen for v2.

#2 is doable, although I'm not incredibly happy with just cramming a bunch of stuff into createOffer()

#3 is doable without any breaking changes, although it's already relatively easy to implement yourself (just call getOffers() and check each one)

I'm planning on releasing a new major version of steam-tradeoffer-manager of v2.0.0.

So far, what I'm planning to do is:

• Move token and message out of the TradeOffer#send() method and into methods like setMessage and setAccessToken
• Hard requirement for node.js v4.0.0 or later (currently package.json suggests that you need v4 or later, but v2 would make this an absolute requirement)
• This should be addressed.

Since this is a major change and they're meant to be few and far between, there's no point in wasting it! If you have any suggestions of stuff that could be added, or things that have just annoyed you, I'd love to hear them!