d0fc0114da66
Query account test run counts
Same as /workspaces/{workspace_id}/reports/usage/testRunCounts but aggregates across every active workspace the authenticated caller has access to within the account. Use this endpoint for account-wide usage dashboards where you want a single aggregated bucket per time period, or pair it with group_by=workspace to produce a per-workspace breakdown of test run counts.
To scope the query to a single workspace within the account (for example, to reuse the same account-level API key while drilling into one workspace), pass its identifier as the workspace_id query parameter. When workspace_id is provided, the caller must still have access to that workspace.
All filter (application_id, plan_id, test_type), granularity, group_by, and time-range rules are identical to the workspace-level endpoint. All timestamps are Unix epoch milliseconds.
Path parameters
The account ID
Query parameters
Inclusive start of the time range to report on, as Unix epoch milliseconds. Must be strictly less than end_time.
Exclusive end of the time range to report on, as Unix epoch milliseconds. Must be strictly greater than start_time. The total window end_time - start_time is capped by granularity: 90 days for daily, 400 days for weekly or monthly. Requests exceeding the cap return HTTP 400.
Time bucket size for the response. Valid values are daily, weekly, and monthly. Daily buckets start at midnight UTC. Weekly buckets follow ISO-8601 week boundaries (Monday 00:00 UTC). Monthly buckets align with the first day of each calendar month at 00:00 UTC.
Optional dimension to break the response down by. Without group_by, each time bucket aggregates all matching runs. With group_by set, each time bucket is further split by the grouping value and the group_id field on each bucket identifies which plan, application, or workspace it represents (workspace only appears on account-level endpoints). Buckets are emitted for every (period, group_id) combination that has at least one matching run; combinations with zero runs are omitted.
Filter results to runs associated with a specific mabl application. Only runs whose application_id matches this value exactly are included. Combined additively with other filters (plan_id, test_type) — runs must match all provided filters.
Filter results to runs that were part of executions of a specific test plan. Useful for attributing usage to a particular CI pipeline, schedule, or deployment trigger. Runs not associated with any plan (for example, ad-hoc runs from the Trainer) are excluded when this filter is set.
Filter results to runs of a specific test type. Valid values are browser (UI automation), api (REST API tests), mobile, and performance. Useful when a workspace exercises multiple test types and you want to report on them independently — for example, to split UI-automation usage from API-test usage in an attribution dashboard. When omitted, all test types are included.
Optional identifier of a single workspace within the account to scope the response to. When omitted, the response aggregates across every workspace the authenticated caller has access to in the account. When provided, the caller must still have access to that workspace and the workspace must belong to the account in the path parameter.
Response
Test run counts grouped by time buckets