Dr. McKay

So basically you want to show a user their inventory on your site, and have them pick items from their inventory, then have your bots send a trade offer for those items?

You can't get a trade URL for another user without asking them. That would defeat the entire point of trade URLs (which is that you can't trade someone unless they give you their URL). If you're friends with the user, you don't need their trade URL/token.

The best way to make sure that you don't miss (many) confirmations is to use the same device ID for every confirmation request (on the account). If you use my libraries for confirmations, then you'll always use the same device ID. If you use a node app alongside a real phone, then there can be problems.

Hooks for polling is kind of weird in my opinion. What's your use case for declining old incoming offers? There's no limit there and I don't see any reason why you wouldn't be able to act on an offer immediately when newOffer is emitted.

There are HTTP hooks that you can use to override the proxy per-request.

This is interesting. I've never experienced any kind of delay for offers which don't need confirmation. Are you 100% sure that the offer is "sent" and not pending confirmation (which is being auto-confirmed or something)?

Only in node?

Not presently. Are you confirming stuff in node and on a real phone?

Steam is Steam.

The only receivedOfferChanged notification is for an active received offer going into another state (decrement of "pending active offers" notification count). 5 seconds should be okay.

As of v1.20.0, you can pass your own SteamCommunity to the constructor of TradeOfferManager. You can pass your own request to the SteamCommunity constructor and you can specify a proxy to request via request.defaults.

Using the Steam client is the fastest way to get notifications, but you still need polling to make sure you get everything (Steam doesn't send notifications when offers you send in which you receive no items are accepted, for example). Polling every second is overkill, but is possible.

That's a known Steam issue. Some confirmations just aren't shown by Steam.

https://github.com/MrJohz/appdirectory/issues

Yes.

I think I'm also going to change how poll data saving/restoration works, making it a string instead of an object, removing the need to JSON.stringify and JSON.parse.

Deploying from GitHub is a bad idea; use npm instead.

Nobody can really help without seeing your code.

newOffer isn't emitted for sent offers. Also, please update to the latest version.

Read the documentation. Specifically you need to save the steamguard value from the callback of login and provide it to subsequent calls to login.

Reposting this as I would like some feedback if anyone has it. At this point I like the trade URL idea enough that I'm potentially willing to just accept the risks and put a big bold warning in the docs.

Good catch, that's indeed a bug. Fixed in v1.20.2. Were you on the beta version when you first made this thread?

You have no options with steam-tradeoffer-manager. There might be some modules that scrape the HTML instead, but you're in for a really bad time if you try that. I don't know what it's called or if it's maintained.

You use node-steam-totp to generate a login code from your shared_secret, and pass it to node-steamcommunity's login method as twoFactorCode.

That really doesn't have any place in this module.