Coaching availability metadata and roster API request
Why
Sales is bringing the Workbench coverage renderer online against Coaching v2 GET /api/v2/coaching/availability. The current endpoint is enough for interval rendering because it returns coach ids, market ids, daily free intervals, and booking overlays for a scoped time window.
The operator-facing renderer still needs display metadata so Sales does not hard-code Coaching-owned labels or infer identity details from ids. The current response does not include coach display labels, market display names, or market timezone metadata. Sales can show raw coach ids for now, but that is not a good long-term operator surface.
Sales also needs a coach roster read that can be scoped by organization_id and market or service area. Weekly coverage currently needs a coach dropdown before an operator picks a single coach. Sales can hydrate that dropdown from an availability read as an interim path, but that couples a roster concern to a windowed availability query and makes the UX depend on availability payload shape rather than a stable roster surface.
What
Sales has implemented daily all-coach lanes and weekly single-coach lanes using the current availability endpoint. The Sales proxy calls Coaching with organization_id, service_area_id, optional coach_id, window_start, and window_end.
Two contract questions surfaced while wiring the renderer. First, should Coaching extend the availability response with display metadata, for example coach label, market display name, and timezone, or should Coaching publish a lightweight roster or metadata endpoint for Sales to call alongside availability? Second, should Coaching expose a public v2 coach roster read scoped by organization_id plus market_id or service_area_id so Sales can populate coach selectors without first reading availability lanes? Third, the contract README mentions an optional market_id filter, but the current Coaching route implementation appears to read service_area_id and not market_id. Sales can continue scoping by service_area_id, but we need Coaching to confirm whether market_id remains part of the public availability contract.
Asks
Please reply with Coaching's preferred shape for display metadata. The acceptable outcomes from Sales' side are an enriched availability response, a small companion endpoint, or a written confirmation that Sales should source those labels from Platform instead.
Please also reply with Coaching's preferred roster-read shape for Sales coach selectors. Sales needs at least coach_id and an operator-readable label, scoped by organization and market or service area. Status and coverage flags would be useful if Coaching wants Sales to hide archived or out-of-scope coaches consistently with Coaching's own roster.
Please also confirm whether market_id is still a supported public availability filter, or whether service_area_id is the canonical filter for this route.
References
coordination/contracts/coach-availability/README.v2.mdcoaching/app/api/v2/coaching/availability/route.tssales/app/api/coaching/availability/route.ts