All Activity

Hey guys. I have asked gpt5.5 to fix it. (With the samples from this thread) And telling it that it needs to change the headers to prevent akamai WAF. This was the set of headers that works for 95 percent of times: const headers = { 'Sec-Fetch-Dest': 'empty', 'Sec-Fetch-Mode': 'cors', 'Sec-Fetch-Site': 'same-origin', }; Although, some endpoints needed some more tuning. (E.g. getting partner details after creating an offer) So right now, i use this to change header dynamically: I have been using this for the past 36 hours and it is working fine. Is there anything suspicious about this? Is there a ban risk? (I don't think so myself, but wanted to share it)

This option also turned out to be quite working, for me it does not even require changing the Accept-Encoding, the key is to transfer Accept and sec-fetch-user. headers: { //"User-Agent": "Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Mobile Safari/537.36", "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8", //"Accept-Encoding": "gzip, deflate, br, zstd", "Accept-Language": "en-US,en;q=0.9", "sec-ch-ua": "\"Chromium\";v=\"140\", \"Not=A?Brand\";v=\"24\", \"Google Chrome\";v=\"140\"", "sec-ch-ua-mobile": "?1", "sec-ch-ua-platform": "\"Android\"", "sec-fetch-dest": "document", "sec-fetch-mode": "navigate", "sec-fetch-site": "same-origin", "sec-fetch-user": "?1", "upgrade-insecure-requests": "1" }

It's absolutely crazy, every time i delete one parameter, everything starts to work. What is the logic behind this? headers: { 'Accept-Encoding': 'zstd', // 🤪 },

thanks so much

Fix CEconItem crash when "Tradable/Marketable After" date isn't day-first by @GVRLNKMK in #370 Fix login hanging indefinitely on steam-session timeout by @lrftw in #369 Full Changelog: v3.50.1...v3.50.2 View on GitHub

This helped me with inventory requests, thanks

Error 429 appeared again, this entry fixed the situation, but idk for how long: 'Accept-Encoding': 'br, zstd'

Nope, I test requests one by one and still got a few errors

do you have 100% success rate? it's still gives me rate limit from time to time

Thanks for the feedback guys! This helped me with trade confirmations when testing, thanks! Nothing works for inventory requests yet. I'll take a closer look at real site requests later.

Here is a cleaner version if you encounter problems. Still not working %100, randomly works. As on some steamcommunity versions, that method would cause a crash. if (this._options.request) { return reject(new Error('SteamCommunity.login() is incompatible with node-steamcommunity v3\'s usage of \'request\'. If you need to specify a custom \'request\' instance (e.g. when using a proxy), use https://www.npmjs.com/package/steam-session directly to log onto Steam.')); } const SteamCommunity = require('steamcommunity'); const community = new SteamCommunity(); // Patch before confirmations — login doesn't use this.request community.request = community.request.defaults({ headers: { 'Accept-Encoding': 'gzip, deflate, br' } });

For me, this method has not changed anything at all. I consistently receive cookies from the steam-session, setCookies() in steamcommunity and tradeoffer-manager work stably, but as soon as I try to send an exchange from the bot or get a link to the exchange bot getTradeURL(), I get error 429 Works for me: request: Request.defaults({ proxy: proxy, headers: { 'Accept-Encoding': 'deflate, br, zstd' } })

Hello, I have been having problems loading my inventory since yesterday and I keep getting the 429 warning. I updated all the modules but my problem is still not solved and I am not able to load my inventory. How should I solve my problem? Thanks

Hello, I have been having problems loading my inventory since yesterday and I keep getting the 429 warning. I updated all the modules but my problem is still not solved and I am not able to load my inventory. How should I solve my problem? Thanks

receiving ofc. Trying to find the way to minimize it

Yes, I do. Using trade offer manager which uses steamcommunity with the new headers defined. Endpoints like offerslist however don't seem to be returning 429's, only the confirmations endpoints do. Are you not receiving any 429's yourself when trying to confirm offers?

do you call other api endpoints on same proxies? inventories, offerslist and so on

Yes, didn't have these 429's yesterday with the same Proxy setup. All proxies are residential.

do you use 1 account per 1 proxy?

This seems to be a part of the solution. The confirmations are working like 60-70% of the time now but for the other 30-40% error 429 is still getting returned. Thank you for sharing though.

here is easy fix: const request = require('request'); const SteamCommunity = require('steamcommunity'); let community = new SteamCommunity({ request: request.defaults({ headers: { 'Accept-Encoding': 'gzip, deflate, br' } }) }); if you use proxy: request: request.defaults({ proxy: proxyUrl, headers: { 'Accept-Encoding': 'gzip, deflate, br' } }) This is not rate limiting. Steam's WAF now fingerprints the Accept-Encoding request header. The legacy request package (which node-steamcommunity uses internally with gzip: true) sends exactly Accept-Encoding: gzip, deflate — real browsers always include br as well. Steam now rejects the bot-like values outright: Accept-Encoding sent Response gzip, deflate (request lib default) 429 gzip 429 gzip, deflate, br 200 gzip, deflate, br, zstd 200 Same IP, same endpoint, seconds apart — only the header changes the outcome. api.steampowered.com is not affected.

I'm having the same issues with my bots. I can also see that a lot of sites are struggling with trading bots while some have already adapted, likely need an update to steamcommunity package.

Is it just me or today something happend with rate limits again? Trade confirmation on all of my bots goes right into 429 error, even though they use different IPs and accounts and it's no more than 4 trade per hour Same with market confirmations. I saw on the forum that getTimeOffset was strict before, but I never experienced something like this, hope it's temporary.... And I also have troubles with inventory loading... On my PC if I load inventory from the browser everything seems ok, but on the same PC using a script I get 429 on the first request... It used to be the same. Something is not right... I use edited version of inventory loading. Were there any changes in requests?

any workaround regarding this?

fix: Invalid time value by @ricardocefet2018 in #367 Full Changelog: v3.50.0...v3.50.1 View on GitHub