Hey everyone,
I've been building a private local dashboard called Torn Assistant, mostly out of frustration with checking the same info manually across a bunch of pages and spreadsheets. It now covers travel, item prices, inventory value, and target tracking.
I figured the inventory module would be the easy part: pull quantities, apply prices, save a snapshot, done. Turned out to be messier than expected.
When I started, the inventory endpoint I needed wasn't available through the API, so I built a temporary fallback: open the inventory page manually, click an export button, let a passive Tampermonkey script read the visible items, send that to my local app, store a snapshot in SQLite. It worked, but page scraping has obvious limits, the page can be partially loaded, UI text can get mistaken for item data, and any interface change can break the selectors.
Inventory data eventually showed up in API v2, which is cleaner and more structured, but it didn't fully solve the problem. API responses can be cached or served per category, reasonable for reducing load and preventing abuse, but it means a valid response doesn't always reflect your latest action. A manual page read might be more recent, but also incomplete or less reliable.
Example:
14:00 — inventory pulled via API
14:12 — items sold
14:15 — manual export shows the new quantities
14:20 — API still returns the old cached state
Neither source is "wrong" here, they're just describing different moments with different tradeoffs. So Torn Assistant now keeps the source and timestamp on every observation instead of quietly overwriting one with the other, and snapshots get tagged as complete, partial, or unknown, mainly so a partial read never gets misread as "everything else was sold."
The next problem is historical valuation. If estimated inventory value jumps from $100m to $115m, I want to know whether that's inventory movement (items added/removed) or market movement (prices shifted on stuff I already had). That means keeping not just quantities per snapshot, but the prices used at the time too.
The official API dev thread hints that more historical snapshot data might land eventually, so until then I'm maintaining my own history while trying to keep things flexible enough to slot in official data later.
Curious how others have handled this kind of thing: dealing with data that's valid but intentionally cached, tagging partial observations, resolving conflicts between structured API data and a more recent-but-messier page read. Also interested in approaches to historical valuation, or estimating something closer to realistic liquidation value instead of a pure theoretical market total.
The tool stays local, read-only, and still very much a work in progress. What started as "save time on repetitive tracking" has turned into a genuinely interesting problem around caching, data provenance, and historical valuation.