Thank you for the web API in 4.3, it is an extremely useful addition. The /api/v1/products routes, the clear error messages and the /routes and /commands catalogs made it easy to build on, and the Roadmap mention of a fuller web API for 1.0 is great to see.
The gap: the read side covers products only. The 240 commands all take an EntityId, but nothing under /api/v1 says which entities exist, what they are, where they are or how they are doing. A tool can see that steel is short, but not which machine is starved, blocked or unpowered.
Suggestion: a read-only GET /api/v1/entities route.
- Filters: ids, protoId, and optionally a map rectangle. A "since" tick parameter would let clients poll only what changed.
- Per entity: id, protoId, display name (including player-set names), category, tile position, footprint, and flags for constructed / under construction / enabled / paused / broken.
- For machines (a detail option or a per-entity route): the active recipe and the productivity counter the game already keeps (working / missing input / full output / cannot work, current and previous months).
Why:
- Finding bottlenecks: "which machines are idle because their output is full" is the most common balancing question, and the data already exists inside the game for the in-game inspector.
- Closing the loop with commands: commands can already change recipes, sliders and priorities, but a tool has no way to know which entity to change. Today it can only guess ids.
- Fewer mods: dashboards and calculators currently need a custom mod per game version. A stable route would survive updates.
- Ratio planning: live per-machine-type utilization lets players size a production chain from real data instead of guessing.
For scale, a late-game base of mine had about 1,900 static entities (680 of them transport pillars), so a since parameter, ids and a type filter would keep responses small.
Thanks again for building this.