Capacity
Query team workload, utilization metrics, and member availability for scheduling and routing decisions.
Query capacity
Uses team:read, which publishable keys may hold — so members are identified by id only, with no names, emails or avatars. Resolve those ids through GET /team/members/{id} with a secret key holding team:members:read.
capacity.members is paginated (limit, default 50; offset). capacity.overview and capacity.timeline are always organization-wide and do not change as you page — read pagination.total for the member count, never members.length. Date ranges are capped at 92 days.
| Prop | Type | Default |
|---|---|---|
start_date | ISO 8601 | - |
end_date | ISO 8601 | - |
team_id | string | - |
member_id | string | - |
group_by | "day" | "week" | "month" | - |
Response
Key fields
| Prop | Type | Default |
|---|---|---|
overview.average_utilization | 0.0 – 1.0 | - |
members[].capacity.utilization | 0.0 – 1.0 | - |
members[].capacity.available_slots | integer | - |
members[].workload.booked_hours | float | - |
Common patterns
Prevent overloading a member — filter by capacity.utilization < 0.8 before passing assign_to to a booking create:
Surface remaining capacity in your UI — show capacity.available_slots as "X slots remaining" next to each team member.
Track team health over time — plot utilization across timeline entries to identify members at risk of burnout or consistent under-utilization.