Dr. McKay

Don't reconnect as a result of disconnected. As per the documentation (please read it!), it will automatically reconnect as long as you haven't explicitly disabled that feature (and even then, if I remember correctly it should emit error instead of disconnected). Why are you waiting 15 seconds to relog after your session expires? You can safely do it immediately. As previously suggested, you should keep track of when you last tried to relog and throttle it to avoid spamming logins. Checking isOurOffer inside of newOffer is unnecessary; it will only be emitted for new incoming offers.

Have you tried adding periods to your sentences? In all honesty, you shouldn't be getting 429s from trade offer polls. The WebAPI doesn't do rate-limiting like that. Where specifically are you getting 429 from?

The most effective way to handle confirmations (in terms of on your end, on the user experience, and on Steam servers) is to just check confirmations manually whenever you send/accept an offer that requires confirmation. Try a couple times if you have to (no more than 3) if it isn't in the list, and if it isn't then just cancel the offer and give the user an error.

The fact that you're asking this indicates to me that it's too hard for you. I suggest that you take some tutorials and get some coding experience before you start trying to build a full site like this.

Well, for one thing, your node version is prehistoric. Update it.

You aren't up to date.

That should be all you need. If steam-user isn't up to date, then InvalidPassword might indicate that Steam is rate-limiting your logins.

Glad you got that resolved. For future reference, you could do community.on('debug', console.log); for debug output.

It's basically your responsibility to manually recheck and handle any double-handles that might arise.

Confirmations work fine for me.

If you need to get items from them, you have them make their inventory public. If you're only sending items, then you can just send offers normally and Steam won't block you.

You're doing that in the wrong place. The example accepts every offer. You need to write your code inside of the newOffer event.

Well, you're only accessing item 0 of the array. You want to use a loop of some kind, or forEach. Please google this is you don't understand it, it's a fundamental concept.

You somehow did it wrong. Couldn't tell you any more without seeing your code.

Did you set a language in the constructor? If you don't, there will be no descriptions (including market_name) present. If you do, then market_name will be a property of each object in the arrays.

Accepting all gift offers is very easy. All you need to do is make sure that itemsToGive.length is 0 and itemsToReceive.length is > 0 when a new offer comes in. Grabbing Steam Market price is a bit more challenging, and it's subject to some relatively strict IP rate-limits. Regardless, it should be possible with steamcommunity and steam-tradeoffer-manager.

If you do it right, it doesn't really matter how many processes you're using. Databases remain consistent regardless of how many processes are accessing them, provided you're querying correctly.

v3.24.0 adds support for the new pagination mechanism. How to use it is kinda confusing now.... If anyone has questions after reading the new documentation, please feel free to ask here.

No, seeing as how steam-tradeoffer-manager doesn't handle any logging in at all. Please direct your question to the board for whichever module you're using to login.

steam-tradeoffer-manager does not request that page. Consequently, it cannot trigger that CAPTCHA. Steam Inventory Helper does, in fact, request that page. Quite frequently, I believe. In fact, I believe SIH to be the reason why Valve added the CAPTCHA in the first place.

If there are 3 requests in flight when your session expires and they all fail, then sessionExpired could be emitted 3 times, so you'd try to log on 3 times. You don't need to explicitly stop it, no.

Looks good. You might want to rate-limit calls to webLogOn though, as sessionExpired could be emitted with any frequency.

That's against the Steam Subscriber Agreement.

You're already using webSession to call setCookies. That's all you need to do to handle those cookies. Cookies from relogs will also arrive in that event. The steamcommunity sessionExpired event will still work for determining that your cookies have gone bad. Cookies from a SteamUser session will last at most as long as your Steam connection, but Steam has a tendency to kill them whenever it pleases (as with all session cookies).