We use the Workload Capacity API (get_workload_capacity) to power a department-level dashboard that mirrors the Workload view. The API covers nearly everything correctly: subtasks, spanning tasks, closed tasks, group-assigned tasks, and standard time estimate spreading. However, two Workload view features produce values that are invisible to the API, causing discrepancies that undermine trust in API-sourced tooling. Feature 1: Per-assignee time estimates Business+ allows setting individual time estimates per assignee on a multi-assignee task (e.g. Daniel 4h, Jonathan 4h, Ezgi 0h on a 10h task). The Workload view renders these correctly, but neither the Task API nor the Workload Capacity API exposes the per-assignee breakdown. The Task API returns only the total timeEstimate. The Workload Capacity API sometimes applies the split internally but not consistently, and the per-assignee values are never returned in the response. Requested: Add a time_estimates_per_assignee field to the Task API response (or a dedicated endpoint) that returns each assignee's individual estimate when set. Feature 2: "Modify work by day" allocations The Workload view allows manually redistributing a task's hours across specific days (e.g. moving a 10h task from even M-F spreading to 0-0-0-5-5). The API uses the standard spreading algorithm and does not reflect these manual daily adjustments. Requested: Expose the daily hour allocations set via "Modify work by day" in the Workload Capacity API response, or as a per-task field. Impact: Any team building dashboards, reports, or automations on top of the Workload view data hits this wall. The workaround (telling users "the numbers are close but not exact") erodes adoption. These two endpoints would make the API a true mirror of the Workload view.