Dr. McKay

You can't, and there's no need. It'll give you error 403 if the inventory is private.

A proxy is not a magical 429-be-gone. I advise that you don't use the confirmation checker at all (or if you do, set it very high, like 5 minutes). Using acceptConfirmationForObject should work fine.

this.client.users[steam_id] is undefined? When are you calling this? Very soon after logon? Some time after?

You need a license before you can play any game. Some older free to play games (like TF2) are in package 0, which is automatically granted to all Steam accounts (except anonymous ones). Newer free to play games have what are called "free on demand" packages, which you need to request ("demand") prior to playing. You can use the requestFreeLicense method I just added in v3.19.0 for that.

Please show the code you're using to look them up in client.users.

Friends do count as users we've encountered. That said, to be 100% safe it might be better to do it your way and check if the user's data is present and request it if not, but that shouldn't be necessary for friends (then again, this is Steam we're talking about).

There is not, because there's no way to kick a user from a group via the Steam client and thus there's no message to do so via a client connection. You can do it with node-steamcommunity: https://github.com/DoctorMcKay/node-steamcommunity/wiki/CSteamGroup#kicksteamid-callback

Update to v3.30.6 and this should be fixed.

You shouldn't need to do the accept on a timeout. You said the confirmation checker is going slow, once every two minutes? That should be fine for 15 accounts, probably even if they all hit it at once. Would it really hurt to try disabling the automatic check for a bit?

1. Is the bot itself online on Steam? You can't get some persona data unless you're online. 2. Since it appears that you're only sending stuff to friends, there's no need to use getPersonas to get up to date data. There is a property (I think it's users?) which contains up to date persona data for all friends, provided you own state isn't offline. Steam sends updates for friends automatically.

Strange, that really shouldn't be doing that then... How frequently are you sending offers that need confirmation? Also, could you use SteamCommunity's HTTP post hook to see which specific request is failing, whether it's the request to load the confirmation list or the one to actually approve it?

How many bots are you running on a single IP?

You're most likely using fs.writeFile('pollData.json', JSON.stringify(pollData)); inside of the pollData event. Node doesn't like it if you use writeFile without a callback anymore. All you need to do is change it to fs.writeFile('pollData.json', JSON.stringify(pollData), function() {});

That license grants you access to package 15740. You can get info about a package using getProductInfo's second argument. A package contains one or more apps, so if you want to translate a license into an app name then you need to lookup the package and then lookup the apps contained in that package. Use JSON.stringify to get full details for an object, or alternatively call console.log on a lower level (e.g. console.log(res[730].appinfo)).

You could perhaps use the async module.

Synchronous I/O functions are contrary to Node's paradigm and so aren't supported. Or is that not what you're asking?

Steam's reboot about five minutes ago seems to have fixed this.

That's no different from how steam-user does it.

I'm not sure I would bother. It's starting to look to me as if webLogOn just won't work at all.

You could try using this: https://github.com/DoctorMcKay/node-steamcommunity/wiki/SteamCommunity#marketsearchoptions-callback

https://steamerrors.com/26

Your screenshot showed your API key, so I removed it. It doesn't look like you're sending a trade offer at all in your screenshot.

console.log('Offer ' + offer.id +' sent, but requires confirmation'); console.log('Offer '+ offer.id +' sent successfully'); Neither of these are running?

It's starting to appear webLogOn will fail if you already have a valid web session. I'm unsure as to whether this is a time-based limit or not, but I can reliably get 403s if I call webLogOn 1 second after webSession gets emitted. Relogging the CM session will work more often than not (all the time? unsure).

I've been investigating this for the past hour and a half or so, and it appears that Valve did indeed break something with client-based web logons last night. The API is giving quite a lot of 403s with the same error message that you get if you use a bad nonce. Therefore, my suspicion is that there's some kind of miscommunication between the CM (the server which most likely generates the nonce and issues it to you), and whichever server consumes those nonces to turn them into cookies. I've tried adding some delays just in case the communication between those servers is slow, but that doesn't appear to have helped anything. Re-logging your client seems to solve the problem, at least temporarily. You may want to try doing that if you don't get a web session within a reasonable amount of time after requesting one. I've alerted Valve, but there's no telling if or when they'll take action.