Dr. McKay

https://github.com/DoctorMcKay/node-steam-user#machine-auth-tokens steam-user will automatically handle saving and using your machine auth token, but if you're running in an environment where persistent storage isn't possible, you can use the machineAuthToken event to save a token somewhere yourself, and then use it again by passing machineAuthToken to logOn().

Looks like you're calling getPersonas before you're logged on.

Yes, those cookies can be used on steamcommunity.com. Are you using them on a different IP than where you generated them? That can cause issues. Otherwise, I don't know why it wouldn't be working based on your description.

You likely have some TLS interception in your network.

offer.addTheirItem(loserPlayer?.invertoryItem[0].asset); This looks an awful lot like you're trying to create an offer to move items between two different users, neither of which is your bot. That's not possible. If your bot has indeed collected the loserPlayer's item, then this should probably be offer.addMyItem, since it's presently in your bot's inventory.

If you have the 64-bit trade ID, you can use the GetTradeStatus WebAPI method.

Use the getExchangeDetails TradeOffer method to get the new asset ids of the items you received. Exact numbers are not known.

There was a Steam update that broke things in steam-user this week, which could have caused a rate limit error. Make sure everything is up to date and you should be fine.

The versions you pasted have the fixes that were just published. What's the exact error you're encountering?

Steam will rate limit your logins, even if you don't have any failed logins. In my experience, 10 logins at the same time should work, although if you need to restart your script too quickly you may run into the rate limit. It's possible to run multiple SteamUser instances in one script, or to use separate scripts. It's up to you how to architect your app.

You may be able to use a token generated by steam-session for that access_token.

Not that I'm aware of.

net.js is part of Node.js itself, so you wouldn't really be able to modify it.

It is async. You can't use return inside a callback function and expect the outer function to get the value. To accomplish what you want, you could wrap it in a promise: export const sendBuyOffer = async (manager:TradeOfferManager, withdraw:any) => { const keys = getKeyBalance(manager); console.log('getKeyBalance returns', keys) if (Number(keys) <= withdraw.keys) { // Note the addition of `await` await createTradeOffer(manager, withdraw) // At this point, `resolve()` will have been called in the createTradeOffer function // Or, if sending the offer failed, an Error would have been thrown, which could be caught using try/catch } } const createTradeOffer = (manager:TradeOfferManager, withdraw:any) => { return new Promise((resolve, reject) => { const offer = manager.createOffer(withdraw.steamid) manager.getInventoryContents(TF2_APPID, INV_CONTEXT_ID, true, (err, inv) => { if (err) { return reject(err); } let keys = 0 for (let i = 0; i != inv.length; i++) { let item = inv[i] if (String(item.classid) == '101785959') { offer.addMyItem(item); keys++; } if (keys == withdraw.keys) break } offer.send((err, status) => { if (err) { console.log(err); reject(err); } else { console.log(`Sent offer. Status: ${status}.`); resolve(); } }); }); }); }

The docs are actually really terrible on this and don't properly explain what this does. It doesn't bypass the need to confirm adding the phone number. When you add a number on the Steam UI, sometimes it throws up a warning message but allows you to proceed. I can't think of a case where this happens off-hand, but you used to be able to use VOIP numbers, though you would be warned that using a VOIP number is less secure than a true cell number, but you could click OK and continue. bypassConfirmation is what controls whether these errors come through to your Node app (false = fail with those errors, true = ignore them).

I don't believe guides use that interface.

It probably is. What's the use-case here?

Not at present.

Yes. You should already have the offer ID handy when you sent or accepted a trade offer.

logOff() is not async, no. But you're calling it before you're actually logged on, because you're calling it synchronously along with logOn(). A couple reasons why running steam-user serverless is a bad idea: You can only log on once every 30 seconds because that's how frequently TOTP codes change Steam will start throttling your logon attempts, even if you don't have any failed logons Your request responses will take quite a long time with all the overhead of logging on each time

Using steam-user in a serverless environment is really not a good idea, unless your environment runs very infrequently. the logOff() method isn't doing anything for you because you're calling it synchronously right after logOn(). logOff() does nothing if not already logged on. You'd need to call client.logOff() inside your doTradeStuff method, at the end after everything has been done.

https://steamerrors.com/26 The assetid isn't correct.

Not really, I've never encountered what you're describing.

acceptConfirmationForObject is a method provided by steamcommunity, not by steam-tradeoffer-manager.