Huge thanks for the August 4th round!

This round covers the three remaining own-cartel reads that still force a page visit — the last of the cartel-management views that can't run on the API yet — plus a couple of general reads that would cut a lot of request volume.

The cartel reads use the same gate as the ones you just shipped: the existing Cartel "Access API" permission (Capo-level), own-cartel only, read-only. Nothing here needs a new permission.

---

New cartel selections

Cartel/Missions — the active cartel missions. Per mission: name, period (Daily/Weekly), rarity, objective (the requirement text), progress (current) and target (goal), percent, rewards (vault cash / cartel rep / item), and expires (timestamp or seconds remaining). Optionally a completed / claimable flag. Empty array when there are no active missions.

Lets a leader watch mission progress from a dashboard without opening the Missions page.

Cartel/Smuggling — the submarine and its current run.

• Submarine: status, condition, cargoCapacity, speed, durability, totalRuns, runsSinceUpgrade
• Current run: status, startDate, endDate, requirementsMet, rewardsStatus

This would let the smuggling view — and a "run finished, collect it" reminder — work without walking the page.

Cartel/Vault — the vault figures: total / balance, memberBalance, available, plus the deposit / withdraw / send ledger with from / to and amount, like the other time selections. Re-requested from round 3 since it didn't make the August 4th batch. It's the one cartel-management number a leader still can't read without opening the page.

---

Fewer round-trips (this would help the most)

Multiple IDs in one user request — e.g. user/advanced?ids=1,2,3 returning an array, the way cartel/members already returns the whole roster in a single call.

Re-requested from round 2, and honestly the single most useful item on this list now. A watching tool has to make one call per player, per cycle today. That eats the 200/min budget quickly and hard-caps how many players can be watched at once. Batching user/advanced and user/status by an ID list, even with a modest cap like 20–50 IDs per call, would let the same view cover far more players for a fraction of the requests.

Public-Only data, so no new permission needed.

A cheap "has anything changed?" for own status — some way to wait on a change rather than re-poll: a long-poll, an If-Modified-Since / 304 on user/status, or even a nextChangeAt hint.

Anything waiting on your own energy or life refill, a cooldown clearing, or a jail / hospital release polls on a short timer right now. Being told "nothing changed" cheaply — or being pushed when it does — would take real, steady load off the rate limit. Not essential, but it pairs well with the batching above.

---

Market

A lowest-listing read for an item — given an item ID, the current lowest market offer (price + quantity available), i.e. the top row of /Market?sort=price&dir=asc for that item.

items.itemValue gives the aggregate market value but not the live lowest listing, so any "cheapest right now" or "what would it cost to top this up" figure still has to read the /Market page. A small market?item=<id> selection — or a lowestListing field on items — would let live price checks and cost-to-fill totals run on the API instead.

---

Also handy, not blocking

• A spendable cartel-reputation field on cartel/basic or cartel/perks — the available rep the Perks page shows, distinct from the cartel's total reputation. The perk list is readable via the API now, but affordability still needs a Perks-page visit to know the spendable pool.
• A bounty list / advanced-player-search selection (from round 2) — the in-game Advanced Player Search already supports "has active bounty" and "highest bounty". Exposing that as an API selection would let a tool show open bounties without paging /Bounty by hand.

---

Thanks again — the last round made a real difference to what's possible without scraping.