Get Test Manager Test Runs by Project ID
tm.get_testRunsByProjectIdRetrieve all test runs in a project with details including status, type, counts, and filtering by status, build state, and folder.
Instructions
Retrieves every test run in a LambdaTest Test Manager project: title, folder ID, status, type, build state, objective, tags, distinct test case/environment counts, total test case instances, percent complete, and a pass/failed/skipped/etc. breakdown.
KANEAI RUNS: a run's top-level type field is ALWAYS 'Manual' regardless of whether it's a real manual run or a KaneAI-generated one - it does not distinguish them, despite the name. The actual signal is 'KaneAI-Generated' (the API's is_auteur_generated field) - true for a run KaneAI itself created. Manual and KaneAI test runs are not interchangeable (a manual test case cannot correctly run inside a KaneAI run and vice versa) regardless of the separate 'Editable'/schedule fields - use 'KaneAI-Generated' before calling tm.add_testCasesToTestRun, which refuses to modify any KaneAI-generated run. 'Editable: No' and a schedule name instead indicate the run's composition is currently owned/regenerated by an active KaneAI schedule - a related but separate concern from manual/KaneAI compatibility (a one-off, unscheduled KaneAI run can be 'Editable: Yes' and still be a KaneAI run).
FOLDERS: test runs can be organized into their own folders/subfolders, entirely separate from the folder tree used for test cases (tm.get_foldersByProjectId) - a test run's folder and the folders its individual test cases live in are unrelated concepts and do not share IDs. This is currently the only tool that reliably reports a test run's OWN folder_id - tm.get_testRunById and tm.get_testCaseInstancesByTestRunId both return an empty folder_id for the same run. There is no known endpoint to browse/resolve the test-run folder tree itself (name, parent, path) - only this raw folder_id value is available so far.
TERMINOLOGY: a 'test case instance' is ONE (test case x environment) pairing, not one test case - e.g. 1 test case assigned 2 environments contributes 2 to 'Total Test Case Instances' but only 1 to 'Test Cases'. 'Test Cases' and 'Environments (distinct)' below ARE correctly distinct counts on this endpoint (unlike tm.get_testRunById, where the API's equivalently-named raw fields are all just duplicates of the instance count - that tool works around it by computing its own distinct counts, so both tools' numbers should agree for the same run).
Supports pagination (page, per_page) and filtering by status (e.g. 'Not Started', 'In Progress', 'Passed', 'Failed', 'Skipped'), build_state ('active' or 'archived'), and/or folder_id (the test run's OWN folder - see the Folder ID note above; this is NOT the folder_id of any test case inside the run). Use tm.get_testRunById or tm.get_testCaseInstancesByTestRunId for full detail on a specific run. Read-only; does not modify anything.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| status | No | ||
| per_page | No | ||
| folder_id | No | ||
| project_id | Yes | ||
| build_state | No |