Dr. McKay

Steam.php L31: You don't need to use an API key for this route. Also, requesting a count of items other than 75 or 2000 will run you into strict IP rate limits. L73: You need to match instanceid in addition to classid. Same on L95. L116: You need to check the item's description (the descriptions array) to see if the item is craftable. If it's not, it should contain a description with content matching something like "( Not Usable in Crafting )". Example item Otherwise, seems like it looks fine.

Show your code.

I haven't tested what happens if you try to use getWebCookies on a SteamClient login session. If you're authenticating with steam-user, you should use the cookies from the webSession event instead.

Where are you getting cookies from?

You need to use EAuthTokenPlatformType.SteamClient.

steam-session should be able to handle all your auth needs for you. It's mostly complete at this point.

As far as I'm aware, if a trade is rolled back after it's successfully committed, the trade offer stays in the "accepted" state. Really the only way to know a rollback happened is to either check your trade history or check your inventory and notice that items are gone/replaced.

No, the API method called by getExchangeDetails is the only place to get the trade status.

Every time you login with your password to an account that has mobile 2FA enabled, you'll need to supply a code. It doesn't matter how long you wait.

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

Figure it out, I'm not going to do your job for you. If you're using node-steamcommunity, the requests it's sending are well-formed. If you aren't, then I can't really help you.

It probably has something to do with the reputation of your IP, dunno.

loadUserInventory has been deprecated for years. You should be using getUserInventoryContents.

Yes.

It's definitely stricter, but it seems to be more than 500/day for me.

Yes, Steam's rate limiting is more strict now. You need to make fewer requests or use more IPs.

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.