Dr. McKay

No, the event won't fire if there isn't any HTTP traffic going on. But if you pass the SteamCommunity instance to the constructor of TradeOfferManager, then the manager will use that community for its HTTP requests and so no-session requests triggered by the manager will fire the event.

That warning is normal. It installed successfully.

https://github.com/DoctorMcKay/node-steamcommunity/wiki/SteamCommunity#sessionexpired And yes, refreshing cookies every hour or so isn't a bad idea.

Thanks!

Yeah, that should work.

It'll be an empty array if you received nothing. You need to use the trade ID, not the trade offer ID.

I beg your pardon?

What did you use to start confirmation checking?

Some items can be missing a market_hash_name under normal circumstances (e.g. some H1Z1 items). If name is empty that's a pretty dead giveaway.

If you'd read that page that was linked, you'd know that that's exactly what confirmation polling does.

You should try again later.

You need to re-logon every so often to refresh your session. Using steam-user all you need to do is call webLogOn() periodically (or when stuff starts to break).

All you can do is go online using chatLogon. You can't go "in-game".

Get a bunch of IPs.

Yes, steamcommunity.com has a global rate limit, which applies to the inventory endpoint. I don't know what the limit is exactly, but there is one and you'll start getting 429 if you hit it.

The documentation suggests that you don't go lower than 10 seconds.

Timeouts are just timeouts. There isn't anything that can be done about them, unfortunately. I'm considering removing the "Data temporarily unavailable" error. That error is returned when the API call succeeds, but the returned offer has no items on either side. I think there's probably a better way to handle that.

Which polling error is more frequent?

Please tell me what the actual errors are.

Yes.

The event is emitted once per offer. If you encounter an error while processing it, it's your responsibility to queue it for later processing.

Sorry for the late reply. Does that specific offer always appear to be empty?

You can't track a specific item across a trade. You can get the IDs of the new items you received in a trade from the trade receipt page (steam-tradeoffer-manager has a method for this), but there is no defined order of items in the receipt. You can match inputs to outputs using their market_name and other defining characteristics, but if you have two identical items in a trade, there's no way to know for sure which specific item is which.

Firstly, you need to understand that Steam is completely awful, horrible, and unreliable. It depends on how quickly you need to process offers. If you're going to be acting on offers that users send to you or on offers that you send where you receive items, then a higher interval is fine if you provide a node-steam-user object, which provides notifications. Generally, 30 seconds is enough but you can go down to 5 or 10. How frequently are you getting errors, and what do they say? If they're extremely frequent, then there's probably something wrong on your end. More inventory capacity is the primary benefit of getting more bots, but you also need to keep in mind that you can only have 30 outgoing active offers at a time. If you need to have more active trade offers, then you need more bots. Performance-wise, there isn't really a difference. It's mostly just because cases are plentiful and mostly worthless. Banning them keeps inventory space available for items that are worth more. It comes down to preference and user experience. Personally, I think that having the user pick their items on your site and then having your bot send them an offer is the best way. This ensures that you have the user's valid trade URL. It also ensures that the user can only create an offer using items that you allow. If you have the user send you the offer, they can put anything into it and you'll just have to decline/counter invalid trades. As far as downsides, doing it this way means that you need to load users' inventories on your end. Loading inventories is pretty heavily rate-limited by Steam by IP.

The page I linked is pretty basic.