New request limits? (429 error)

[Nickers]

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?

Edited 10 hours ago by Nickers

[Devx09]

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.

[JVz]

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.

[Devx09]

1 hour ago, JVz said:

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.

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.

[JVz]

do you use 1 account per 1 proxy?

[Devx09]

46 minutes ago, JVz said:

do you use 1 account per 1 proxy?

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

[JVz]

26 minutes ago, Devx09 said:

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

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

[Devx09]

14 minutes ago, JVz said:

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

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?

Edited 18 minutes ago by Devx09