How an Automated Buyer Picks the Cheapest Listing (Every Time)
"Buy the cheapest one" sounds like a single instruction. In practice it's a seven-step pipeline, and every step exists because skipping it once cost somebody money. Let's walk one purchase — a single Dreams & Nightmares Case on an ordinary morning — through the whole machine.
The setup: your plan says a slice of today's budget goes to a Dreams & Nightmares Case, with a max price you set weeks ago. Two marketplaces are in play — DMarket, priced in dollars, and SkinBaron, priced in euros. Here's what happens between "the schedule fires" and "the case is yours."
The pipeline, step by step
- Resolve the item. Before anything is priced, the name in your config is validated against live market listings. "Dreams & Nightmares Case" resolves; a typo doesn't, and the run halts loudly instead of guessing. This is the check that once caught a config asking for a "Gamma 3 Case" — an item that has never existed.
- Fetch both books. The buyer pulls current listings for the exact item from DMarket and from SkinBaron. Not cached prices from an hour ago — live asks, because case prices move and a comparison against stale data is a comparison against fiction.
- Convert the euro side. SkinBaron's ask is in EUR. It gets converted to USD at a daily rate fetched fresh, so both venues are compared in one currency on equal footing. The rate used is recorded, because "what exchange rate did you charge me?" should always have an exact answer — the reasoning is in converting EUR listings fairly.
- Compare, then gate on the cap. Say DMarket's best ask converts to a few cents more than SkinBaron's. SkinBaron wins the comparison — but the winning price still has to clear your per-item ceiling. Cheaper-of-two is not the same as cheap enough; if both venues are above your max-price line, today's answer is no buy, and the report will say so plainly.
- Check the budget and the log. Two more gates before money moves: does this purchase fit inside today's remaining budget (under the hard cap), and has this run already bought this item? The purchase log is consulted so that a re-fired schedule can't buy twice — the property covered in why good bots never buy twice.
- Execute on the winner. Only now does the buyer place the order on the cheaper venue. One deliberate purchase at a known price — no market-sweeping, no walking up the book.
- Verify and log. The purchase isn't "done" when the API says OK; it's done when the item is confirmed against the account's inventory or pending-delivery state. Then the fill is appended to the ledger — item, venue, price in both currencies, rate, timestamp — money-exact, append-only, committed to git.
Why verification gets its own step
Marketplace APIs occasionally say yes and deliver nothing, or deliver late. On DMarket, purchases have been observed to carry trade locks of roughly two to seven days before withdrawal; SkinBaron delivers via direct Steam trade offers on its own timetable. A buyer that logs "bought" the moment an API call returns will drift out of sync with reality within weeks. So confirmation is checked against what the account actually holds or is owed, and the difference between "purchased" and "delivered" is tracked explicitly — the full journey is mapped in tracking buys from purchase to Steam inventory, and the lock mechanics in trade locks explained.
What the cents add up to
On this one purchase, the venue comparison might have saved a few cents; on another day, a few percent. It looks trivial per buy — which is exactly why humans doing this manually stop checking after week two. But the pipeline runs every day, across every item on the list, without opinion or fatigue. The founder's own ledger — roughly $19–20 of fills per day across about five cases, plus a weekly CS:GO Weapon Case — crosses this comparison thousands of times a year. The venue gap exists for structural reasons (fees, currency, book depth, explained in cross-market price lag), so collecting it isn't a trick that decays; it's just shopping done properly, forever.
What the pipeline refuses to do
Equally load-bearing is what's absent. The buyer never exceeds the cap "because it's only a little over." It never rebalances your list on its own opinion. It never sells — there is no sell code to misfire. And it never buys quietly: every run produces a report you can read in a minute, and every fill lands in a ledger you can audit in ten. If you want to see what those artifacts look like in practice, anatomy of one automated purchase shows a real one with receipts, and how to read a buy report covers the daily email.
None of this is clever. That's the point. Cleverness in a money-touching pipeline is where bugs live; this is seven boring steps that do one thing each, in order, with a paper trail. The edge isn't intelligence — it's the fact that the machine performs step 2 and step 3 every single day, and you wouldn't.
If you're evaluating any automated buyer — this one or a competitor's — the pipeline above doubles as a checklist. Ask where the comparison happens, what currency it happens in, what stands between an API error and a phantom "purchase," and where the record lives. A tool that can't answer all four in a sentence each hasn't thought about the problem; a tool that answers them differently should be able to say why.