Dr. McKay

The new endpoint has last_assetid, which you should pass as start_assetid for the next request.

Off the top of my head, use start_assetid I think.

Looks like your assetIds variable contains an array of arrays.

async/await doesn't work like that. You'd need to wrap the entire call in a promise and resolve the promise when your callback is done.

This isn't a supported use-case.

I'm not aware of any limits imposed as a result of making trades too quickly, just limits on how many web requests you can make.

You can't. It's not possible to do that kind of thing using the API.

You definitely would want to avoid calling getUserInventoryContents too frequently to avoid Steam rate limiting you, but it shouldn't crash in any case.

I have no idea what I'm looking at.

What have you tried?

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

It shouldn't crash. What error message does it crash with?

Like their Steam profile name, or the nickname you set for them on your account?

Calling getUserDetails is the correct way to check. You'll still get an error if the token is wrong, but not if you're friends with the user.

That could be any number of things, likely coming from a steam-user method.

New version is up: https://github.com/DoctorMcKay/node-steam-session/releases/tag/v0.0.3-alpha

https://github.com/DoctorMcKay/node-steam-user/wiki/SteamChatRoomClient#ackfriendmessagefriendsteamid-timestamp

Not yet, but it will. Maybe this is a little vague, I'll try to rewrite it. This is only talking about a case where you supply a token that wasn't generated using EAuthTokenPlatformType.SteamClient. If the token is invalid for any other reason, you'll get the normal error event with an EResult value (probably InvalidPassword, but I haven't checked).

access_token (client._logOnDetails.access_token) and refreshToken are the same thing. The field in the logon message is named access_token, but steam-user accepts it as refreshToken to make it less confusing which type of token you need to supply (since steam-session returns both an access token and a refresh token). As far as I can tell, the refresh token you receive from steam-session is good for the full 200 days, so you can just keep using it over and over. I'm not aware of a way to get a new refresh token without going through the entire auth flow again. I wouldn't be surprised in the slightest of the official Steam client just pops up the login flow again in 200 days. It's up to you how you store your tokens. Encryption at rest is rarely a bad idea, but it's also pretty useless if you're also storing the keys alongside the encrypted data, for example. Sentry files aren't encrypted either, they're just blobs of random binary data by design.

What version of node and steamcommunity are you running?

You're probably overwriting av somewhere, it seems like it's not a string.

You must use EAuthTokenPlatformType.SteamClient to get a token that's eligible for use with steam-user.

That will log the IDs of the items before they were traded. To get new asset IDs, use the getExchangeDetails method on the TradeOffer object.

Sounds like you might not be up to date. I'd fetch all rows upfront, then request all personas at the same time. Seems good, I think Steam might send you a persona update via the user event for yourself when you set yourself to online; if it does, then waiting to see yourself as online might be all you need.

The order of parameters to the getPersonas callback is err, personas. You have it backwards. The getPersonas function accepts multiple IDs. Why are you calling it individually for each ID? You might need to delay some time after calling setPersona to set yourself online, as you're currently sending the getPersonas requests synchronously at the same time as setPersona, without giving Steam enough time to process that you're now online.