Context: We run an internal finance dashboard (Node/Next.js) that reads staff across all workspaces a given API key has access to, to show a deduplicated headcount KPI and a per-workspace staff table.
Wish / friction: GET /staff is scoped to a single workspace via X-Workspace-Id — there's no way to ask for staff across several workspaces in one call. With N workspaces on the key, we currently do 1x GET /me + Nx GET /staff (one per workspace, parallelized, but still N separate HTTP round trips). We confirmed against the live OpenAPI spec (v1.5.0) that Workspace (returned by /me) only has id/name/slug — no staff data embedded — so there's currently no way to avoid the N+1 pattern.
Requested capability: accept a batch parameter on GET /staff, e.g. GET /staff?workspaceIds=id1,id2,id3, returning staff grouped by workspace in a single response. This collapses N round trips into 1, which matters a lot on cold serverless starts (fresh TLS handshake per external call, no connection reuse).
Why it matters: This N+1 pattern against your API is one of the concrete bottlenecks we identified in our own dashboard's "first load is slow" investigation — it's the least predictable and highest-latency piece of the whole page load, especially on a cold start where there's no warm connection to reuse.
Reported via the freeticket-cli skill (filed here instead of free-admin, which wasn't visible/accessible from our gh account — please re-route if needed).
Context: We run an internal finance dashboard (Node/Next.js) that reads staff across all workspaces a given API key has access to, to show a deduplicated headcount KPI and a per-workspace staff table.
Wish / friction:
GET /staffis scoped to a single workspace viaX-Workspace-Id— there's no way to ask for staff across several workspaces in one call. With N workspaces on the key, we currently do 1xGET /me+ NxGET /staff(one per workspace, parallelized, but still N separate HTTP round trips). We confirmed against the live OpenAPI spec (v1.5.0) thatWorkspace(returned by/me) only hasid/name/slug— no staff data embedded — so there's currently no way to avoid the N+1 pattern.Requested capability: accept a batch parameter on
GET /staff, e.g.GET /staff?workspaceIds=id1,id2,id3, returning staff grouped by workspace in a single response. This collapses N round trips into 1, which matters a lot on cold serverless starts (fresh TLS handshake per external call, no connection reuse).Why it matters: This N+1 pattern against your API is one of the concrete bottlenecks we identified in our own dashboard's "first load is slow" investigation — it's the least predictable and highest-latency piece of the whole page load, especially on a cold start where there's no warm connection to reuse.
Reported via the freeticket-cli skill (filed here instead of free-admin, which wasn't visible/accessible from our gh account — please re-route if needed).