Dr. McKay

You can accept it, but that's unnecessary. All you need to do is accept the confirmation.

You don't need to accept real-time-trade offers. Offers that are created from real-time trades are accepted automatically, you just need to confirm them. The wiki page on GitHub has more information.

Check fromRealTimeTrade and abort if it's true in newOffer.

Trade failures which result in ID changes are infrequent enough that you can fix them manually. Or you could detect when a trade goes InvalidItems and automatically figure out which items in your inventory have unrecorded asset IDs and match the description of the missing items.

classid and instanceid can change whenever they want. And no, they don't include wear for uniqueness.

Yes.

It doesn't work if the trade didn't complete fully, no.

https://github.com/DoctorMcKay/node-steam-tradeoffer-manager/wiki/Real-Time-Trades

offer.getReceivedItems will give you post-trade IDs and descriptions.

In order for that to work, make sure you listen for both unknownOfferSent (for offers that get confirmed by the user before the manager sees them), and sentOfferChanged (for offers that get confirmed by the user after the manager sees them).

Based on some testing I just did, it looks like the "sender" of the offer is actually the party who sent the Steam trade request. If you're receiving trade requests to your bot and accepting them, then the offers are always being "sent" by the human. Since the bot isn't giving anything away and consequently doesn't have to confirm anything, the offers are immediately going "Accepted" once they're visible to you. That's why you aren't getting any events at all. I think I'll add a couple new events to handle real-time-trade offers (realTimeTradeConfirmationRequired and realTimeTradeCompleted sounds good to me).

It's secure as long as you properly secure your code and servers. Valve won't ban you for using this.

It's possible, but due to potential for abuse I don't plan to implement this.

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.