# Running Steam Trading Bots at Scale: What Breaks *2026-08-10 — hunbenji, AssetPay team* A Steam trading bot is easy to write and hard to run. The first version takes an afternoon: log in, poll for trade offers, accept the ones that match. It works. It keeps working right up until you have real inventory, real volume, and a real obligation to credit users correctly — and then every assumption in that afternoon's code turns into an incident. This is what the operational reality looks like, for teams deciding whether to [build it or use a gateway](/blog/skin-payment-gateways-explained). ## A bot is a Steam account, with everything that implies The thing people underestimate is that there is no "bot API." A trading bot is an ordinary Steam account being driven programmatically, and it is subject to every rule, limit and failure mode that applies to a human's account. That means it has a password and a [Steam Mobile Authenticator](https://help.steampowered.com/en/faqs/view/06B0-26E6-2CF8-254C). It has a session that expires. It can be rate-limited. It can be locked. It has a finite inventory. It can be caught by a security check aimed at compromised accounts, because "logs in from a datacentre and trades constantly" is also what a hijacked account looks like. And when it does get locked, it gets locked *with your users' items inside it*. ## The failure modes that actually cost money **Session and authenticator management.** Every bot needs its shared secret and identity secret stored somewhere your application can reach, which means you are now operating a system whose compromise hands an attacker the ability to empty every bot you run. This is the part that turns a side project into a security engagement. **Rate limits you cannot see.** Steam's limits on trade offers, inventory fetches and API calls are neither documented nor constant. You discover them by hitting them, usually at your busiest moment, and the symptom is not a clean error — it's degraded and inconsistent behaviour that looks like a bug in your own code. **Inventory capacity.** Steam inventories are finite. A bot that fills up stops being able to receive trades, so you need distribution logic across a fleet, plus a liquidation or consolidation pipeline that keeps space free. Neither is optional once volume is real. **Steam downtime.** Steam has regular scheduled maintenance and irregular unscheduled outages. During both, trades fail. Your checkout has to degrade gracefully rather than take payments it cannot deliver. **Trade bans and locks.** Accounts get restricted, sometimes for reasons that are never explained. Recovering a locked bot's inventory is slow at best. A fleet has to assume this will happen and be structured so that one loss is survivable. ## Why one bot becomes a fleet The single-bot design fails on capacity, on concurrency, and on risk concentration all at once. So you end up running many, and the fleet introduces its own problems: - **Routing.** Which bot should handle this trade, given current inventory space, recent trade volume, and whether it's already mid-offer with someone else? - **Health checking.** A bot that is logged out, rate-limited or locked has to be detected and taken out of rotation automatically, before it silently swallows deposits. - **Balance.** Items accumulate unevenly. Without rebalancing you get some bots full and idle while others carry everything. - **Observability.** When a user says their deposit never credited, you need to reconstruct exactly what happened across a fleet of accounts, hours later. ## Verification is the part that gets skipped Here's the failure that hurts most, because it doesn't look like a failure. Your system prices a set of items and sends a trade offer. The user waits twenty minutes, then accepts. The items arrive. Your bot sees "trade completed" and credits the user. But *what* arrived? Trade offers can be manipulated between creation and acceptance. Market prices move. If your settlement logic trusts the offer it created rather than verifying the items it actually received against the price it actually quoted, you are crediting on faith. That gap is exploitable, and the exploitation looks exactly like normal traffic until you reconcile the books. Settlement verification — confirming that the completed trade matches the priced offer, item by item — is the difference between a bot that moves items and a system that can take payments. ## The honest build-versus-buy summary None of this is impossible. Teams run their own fleets successfully. But the work is not "write a trading bot," it's: - Secure secret storage and session management for N accounts - Rate-limit discipline against undocumented, shifting limits - Fleet routing, health checks, rebalancing and liquidation - Pricing that holds up under [float, pattern and liquidity variation](/blog/how-cs2-skin-pricing-works) - Settlement verification and reconciliation - Enough monitoring to answer support tickets about individual trades - Someone on call, because Steam does not respect your working hours That's a team and an ongoing operational commitment, not a sprint. For platforms whose actual product is the platform, it's usually the wrong thing to own. The alternative is to let it be someone else's problem and integrate an API. That's what AssetPay is — bots, pricing and settlement behind a merchant API, with signed webhooks your backend can trust. The [docs](/docs) cover the integration, and [contact](/contact) reaches us if you want to talk it through. --- Written by hunbenji — Writes AssetPay's engineering guides: Steam trade mechanics, API integration, and the settlement infrastructure behind skin payments.