Dr. McKay

Yes, because ignorant coders will almost definitely start passing API keys that don't belong to the account they're signed into, and start posting GitHub issues asking what's going on. If you know what you're doing, you can set the apiKey property directly with the correct key, but please make sure you actually know what you're doing.

Chat history is temporary for all chats, even group chats.

As in all callbacks, the first argument is err. And I'm pretty sure you'd want to still use getChatHistory as before.

You should not be using the same id for the first and second parameters. The first parameter is the group chat ID, and the second is the ID of the channel you're looking for. Get rid of the parens around the parameters. That's turning the commas into comma operators, which is not what you want to do.

Active means its state on Steam is Active. Anything that you can accept but haven't yet is active and you should be able to use getUserDetails on it. To get user details for trade offers that are no longer active, you'll need to use the WebAPI.

You cannot call getUserDetails on a trade offer that is not active.

There is absolutely nothing wrong with doing this. I'd recommend that you do it this way, although maybe 15 minutes is too quick. Try 30 minutes and if you still have trouble, lower it to 15.

You're not losing your connection to the Steam servers. Your web session has expired. They're two separate things. When you connect to the Steam CM (the server the Steam client connects to), the CM issues you a "nonce" which is then exchanged for web session cookies via the API. Those session cookies can expire, and so you'll need to get new ones from your still-connected connection to the CM. That's what webLogOn is for. This is exactly what's happening when you see this in your Steam client: Your client is still connected, but the web session is expired. So it needs to get new cookies.

You're accepting offers very wrongly. First, remove the offer.accept(...) around your call to your own accept function. Second, passing offer.accept to setTimeout like that will cause problems because the this reference is lost. For example: function TestObj(name) { this.name = name; } TestObj.prototype.printThis = function() { console.log(this); }; let obj = new TestObj('foobar'); obj.printThis(); setTimeout(obj.printThis, 500); Prints this: TestObj { name: 'foobar' } undefined The reason this happens is because this is set to the reference of the object on which the method was called. So when you call obj.printThis(), the this reference is to obj. But when you pass obj.printThis to setTimeout, what setTimeout sees is something like: function setTimeout(callback, delay) { wait(delay); callback(); } As you can see, when callback is called (which is obj.printThis in this case), there is no object reference on which it's called, so this is undefined. If you want to pass offer.accept to setTimeout like that, you'll need to bind it like this: setTimeout(offer.accept.bind(offer), delay)

https://github.com/DoctorMcKay/node-steam-user#datadirectory

https://github.com/DoctorMcKay/node-steam-tradeoffer-manager/wiki/TradeOfferManager#getoffersfilterhistoricalcutoff-callback

No planned date yet.

Sounds like a plausible explanation.

Just remove the whole startConfirmationChecker line. There's no need to confirm anything if you're never losing items.

Looks like your web session is expiring and your app is coded in such a way that that causes a crash.

Sure. If your database is MySQL, you can use the mysql module.

Download it and drop it into node_modules.

Instead of comparing relationship to a number directly, you should compare to SteamUser.EFriendRelationship.RequestRecipient. You're firing off the addFriend request but then immediately trying to send a chat message and post a comment. Steam sees this as all happening at the same time, and wouldn't have processed your add-friend request when you try to post the comment. You need to wait for friendRelationship to get emitted again, this time with relationship Friend.

https://github.com/DoctorMcKay/node-steam-user#requestfreelicenseappids-callback

https://github.com/DoctorMcKay/node-steam-user#user

Once an account is banned, it's banned for good. You can't just change the phone number and get it unbanned. I also wouldn't use that same phone number anymore since it's now "tainted".

That shouldn't be possible, no.

All accounts linked to a phone number are banned if any account linked to that number is banned. No other criteria matter.

Why not use node-steam-user?

Absolutely. If any account gets banned, all accounts with the same phone number get banned.