Dr. McKay

https://httpstatuses.com/429

That example is old and won't work with v2 (v1 is now unsupported). Code for sending an offer to a friend (without a trade token) with v2 looks like this: var offer = manager.createOffer("[U:1:46143802]"); offer.addMyItem({"appid": 440, "contextid": "assetid": 1234567890}); offer.send(function(err, status) { if (err) { console.log(err); } else { console.log("Offer #" + offer.id + " " + status); } });

I haven't experimented too much with real-time trades, but as far as I can tell it looks like the first party to confirm the real-time trade is the offer "sender". So if your bot is the first party to "click" the green button then your bot is the sender of the trade and consequently the offer won't come in newOffer (I think unknownOfferSent should be emitted?). Depending on the speed of the other user, you may get sentOfferChanged or not. Basically the flow would be one of the two following scenarios: User is fast Bot confirms real-time trade User confirms real-time trade Bot accepts mobile confirmation User accepts mobile confirmation and items are exchanged TradeOfferManager polls, sees the accepted offer, and unknownOfferSent is emitted with state == 3.User isn't as fast Bot confirms real-time trade User confirms real-time trade Bot accepts mobile confirmation TradeOfferManager polls, sees the offer, and unknownOfferSent is emitted with state == 9 (probably) User accepts mobile confirmation and items are exchanged TradeOfferManager polls, sees the accepted offer, and sentOfferChanged is emitted with state == 3If your bot isn't confirming the trade first, then the other user has to confirm it first. Once they do, you get the confirmation on your end, which you need to confirm. TradeOfferManager won't emit newOffer for non-active offers, so if you confirm it before TradeOfferManager sees it, then you won't get any events at all. This doesn't seem like it's super-desirable behavior, so I might add a unknownOfferReceived event for this situation. If you don't confirm it before TradeOfferManager sees it, then you'll get newOffer, and receivedOfferChanged after it's confirmed (and therefore accepted). This is all assuming that I'm correct in that the first party to confirm a real-time trade is the sender of the offer.

You never called setCookies on your offer manager. Listen for the webSession event on the SteamUser for your cookies.

If you have mobile auth enabled on a physical phone, steam-user will just prompt you for a code when it needs one and you can provide it from your phone. If you have a secret, you can use steam-totp to generate a code.

There shouldn't be any need to cancel it. You already have the offer ID, unlike error 16. When you get 504 just wait a bit, check if it's been confirmed, and if not then confirm it again.

steamcommunity has a sessionExpired event. You can also just automatically relog every hour or so, that's what I do.

err.eresult, provided it's available.

"My library" doesn't have limitations, Steam servers impose limitations. They're not exactly published. If you're getting 429, then you're hitting it.

You might want to try logging into the account in a browser and pulling up https://steamcommunity.com/mobileconf/conf, see if that 504s as well. As for telling Valve what you're using, just say you're using SDA I guess. I don't imagine Valve could be hostile toward that, as it isn't exclusively for bot use.

429 does indeed mean that you're being rate-limited, yes.

No idea, ask Valve.

Right.... you didn't see anything.....

Sorry, it was working if you used setCookies but not if you logged in directly. This is fixed in v3.26.1.

That's the very wrong way to fix this. Increase your poll time.

You're kind of meant to use steam-store for store.steampowered.com requests, but I could see how it would be more useful to have that available in steamcommunity, especially since steam-store doesn't offer the HTTP stuff. This is now available in 3.26.0.

Don't reconnect as a result of disconnected. As per the documentation (please read it!), it will automatically reconnect as long as you haven't explicitly disabled that feature (and even then, if I remember correctly it should emit error instead of disconnected). Why are you waiting 15 seconds to relog after your session expires? You can safely do it immediately. As previously suggested, you should keep track of when you last tried to relog and throttle it to avoid spamming logins. Checking isOurOffer inside of newOffer is unnecessary; it will only be emitted for new incoming offers.

Have you tried adding periods to your sentences? In all honesty, you shouldn't be getting 429s from trade offer polls. The WebAPI doesn't do rate-limiting like that. Where specifically are you getting 429 from?

The most effective way to handle confirmations (in terms of on your end, on the user experience, and on Steam servers) is to just check confirmations manually whenever you send/accept an offer that requires confirmation. Try a couple times if you have to (no more than 3) if it isn't in the list, and if it isn't then just cancel the offer and give the user an error.

The fact that you're asking this indicates to me that it's too hard for you. I suggest that you take some tutorials and get some coding experience before you start trying to build a full site like this.

Well, for one thing, your node version is prehistoric. Update it.

You aren't up to date.

That should be all you need. If steam-user isn't up to date, then InvalidPassword might indicate that Steam is rate-limiting your logins.

Glad you got that resolved. For future reference, you could do community.on('debug', console.log); for debug output.

It's basically your responsibility to manually recheck and handle any double-handles that might arise.