We’re expanding the Testmo REST API with new run management capabilities, richer filtering, lookup endpoints, and more — opening up new possibilities for programmatic access to Testmo and laying the groundwork for a range of use cases around our upcoming official Testmo MCP server. Whether you’re building a CI/CD integration, scripting a test workflow, or connecting an AI agent to your test management data, the API now supports the full test management lifecycle.

Specifically, this release adds the ability to:

• Create, update, and delete manual test runs programmatically, selecting specific cases or entire projects
• Filter test cases by name, tags, date ranges, folder hierarchy, and more
• Retrieve lookup data (templates, statuses, configs, states, tags, and milestone types) to discover valid values before performing operations
• Access the full result history for any test case across all runs

The Direction We’re Building Toward

We’re building the official Testmo MCP server. MCP is an open standard that allows AI assistants — tools like Claude — to interact directly with software products using natural language. Rather than writing API calls manually, an AI agent with access to the Testmo MCP server could be asked to “create a regression run for the v2.1 milestone and mark all the authentication tests as passed” — and it would handle that using the Testmo API on your behalf.

For that to work well, the API needs to support the full test management lifecycle: setting up runs, selecting and filtering cases, recording results, and discovering the reference data required to do all of that correctly — what states are available? what templates does this project use? what statuses can I assign?

The changes in this release are an API foundation for the Testmo MCP server. They’re equally useful if you’re building your own integrations or automating test workflows directly — the same capabilities an AI agent needs are the ones a well-designed integration needs. Over time, you may notice API additions that are shaped by MCP use cases rather than traditional direct-integration patterns. We want to be transparent about that direction, and we think it benefits both audiences.

What’s New?

Milestones

The Milestones list endpoint gains a name filter for partial-match searches, along with new date range filters (starts_after, starts_before, due_from, due_to). A new GET /projects/{project_id}/milestone-types endpoint returns the valid type IDs configured for your project.

Manual Runs

The Runs namespace now supports create, update, and delete operations, enabling fully programmatic test run management. You can create a run with include_all: true to include all project cases, or specify individual case IDs to target a precise subset — useful for milestone-scoped or area-specific runs. Runs can be linked to milestones and configurations, and tagged on creation. The list endpoint also gains a name filter.

For lookup support, GET /projects/{project_id}/configs and GET /projects/{project_id}/states return the available configurations and workflow states for a project, making it straightforward to assemble a valid run creation request.

Test Results

A new GET /projects/{project_id}/statuses endpoint returns the full list of available test result statuses with their system names and pass/fail classifications. This makes it straightforward to look up status IDs for use in filtering results or in integrations that process run data.

Case Filters and Content

The GET /projects/{project_id}/cases endpoint receives the most extensive set of additions in this release:

• name — partial match filter
• tags / tag_match — filter by tag names or IDs; control whether all or any must match
• created_after / created_before / updated_from / updated_to — date range filters (ISO 8601 and plain YYYY-MM-DD both accepted)
• folder_id + recursive — filter to a folder and optionally all its sub-folders
• priority, type_id — attribute filters
• POST /projects/{project_id}/cases now validates that custom field keys belong to the case’s template, returning a 422 error if fields are passed that don’t exist in the template.

Case Result History

A new endpoint — GET /projects/{project_id}/cases/{case_id}/result-history — returns a paginated list of all test results recorded against a specific case across all runs, ordered by date descending. This makes it straightforward to retrieve the full testing history for any case programmatically.

Lookup/Reference Data

Seven new GET-only endpoints return reference data for a project. These are designed to help API consumers (and AI agents) discover valid values before performing write operations:

Folders

The GET /projects/{project_id}/folders response now includes a case_count field on each folder, reflecting the total number of test cases in that folder and all of its sub-folders.

Example Usage

Look up reference data before building integrations

A common pattern is to use the new lookup endpoints to discover valid IDs before querying or filtering data:

# Look up milestone types configured for a project
GET /api/v1/projects/1/milestone-types

200 OK
{
    "result": [
        { "id": 1, "name": "Release", "is_default": true },
        { "id": 2, "name": "Sprint", "is_default": false }
    ]
}

# Look up available test result statuses
GET /api/v1/projects/1/statuses

200 OK
{
    "result": [
        { "id": 2, "name": "Passed", "system_name": "passed", "is_passed": true, ... },
        { "id": 3, "name": "Failed", "system_name": "failed", "is_failed": true, ... },
        ...
    ]
}

# Now filter milestones by type, and results by status
GET /api/v1/projects/1/milestones?type_id=1&is_completed=false
GET /api/v1/runs/87/results?status_id=3
        

Filter cases with tags and date range

GET /api/v1/projects/1/cases?tags=smoke,regression&tag_match=all&updated_from=2026-06-01

200 OK
{
    "result": [
        {
            "id": 535,
            "name": "Verify login with 2FA",
            "custom_description": "<p>Tests the full MFA login flow...</p>",
            "custom_steps": [...],
            ...
        },
        ...
    ]
}
        

What This Means for API Users

For teams building CI/CD integrations or internal tooling: You can now fully script test run setup — selecting cases, linking to a milestone, assigning a configuration — directly through the API. Lookup endpoints mean your integration can query valid IDs at runtime rather than maintaining hardcoded configuration values that drift as your Testmo instance changes. The new case filters let you target precisely the tests you need in a single request rather than fetching everything and filtering client-side.

For teams already using the Testmo API for reporting or data extraction: The additions extend what’s possible without adding complexity to existing workflows. The richer case filters reduce the volume of data you need to handle. The case result history endpoint gives you a direct path to the full testing history for any case without aggregating across run results manually.

For teams interested in AI-assisted workflows: These additions form the foundation of the Testmo MCP server currently in development. The same endpoints that will power AI agent interactions are available to you directly — so integrations you build against this API will work alongside the MCP server when it ships.

The full API reference for all new endpoints is available in our documentation.

We Want Your Feedback

These additions represent a significant step in our API roadmap. As we continue to develop the MCP server and the API capabilities it requires, we’d love to hear from you — particularly from teams already building integrations or automation around the Testmo API. If you have comments or suggestions, please let us know! Provide Your Feedback Here!