TestRail 10.9.0 Adds Automation APIs, AI Test Metadata, and Automatic User Deactivation

TestRail 10.9.0 Default (1032) is now available on the default release track. This is a practical update rather than a visual overhaul, focused on automation, integrations, access management, and bug fixes. It reached Early Access on October 6, 2026, followed by the Default release track on October 14, 2026. TestRail says the release adds new automation and integration APIs, performance improvements, automatic user deactivation, and more than 40 fixes. ([support.testrail.com](https://support.testrail.com/hc/en-us/articles/54288720497940-TestRail-10-9-0-Default-1032))

Test management can become a bottleneck even when automated checks already run in CI. Teams still have to recreate runs, synchronize changed records, determine current status, and remove stale user access. TestRail 10.9 addresses those chores through new endpoints and administrative controls.

New APIs remove common automation workarounds

The release's biggest change is its expanded API surface. TestRail now supports POST /rerun_plan/{plan_id} and POST /rerun_run/{run_id}, so integrations can rerun an existing plan or run with a single request. They can also copy assignees instead of rebuilding the run through several separate API calls. ([support.testrail.com](https://support.testrail.com/hc/en-us/articles/54288720497940-TestRail-10-9-0-Default-1032))

A new POST /add_cases_to_run/{run_id} endpoint lets an integration append cases to an existing run without retrieving and resubmitting the full case list. TestRail describes the update as atomic, reducing the risk of conflicting changes when multiple users or services work on the same run.

For reports and dashboards, GET /get_test_states_for_run/{run_id} returns the latest result for each test without returning the complete result history. That suits CI summaries, release dashboards, and milestone reports, where the current state matters more than every previous execution.

Incremental synchronization becomes more practical

TestRail 10.9 extends the updated_after filter to runs, plans, and milestones. Integrations can request only records changed since the previous synchronization instead of repeatedly pulling entire datasets. The release also updates a run's updated_on timestamp when a new test result is added, so result-driven changes can appear in incremental sync jobs. ([support.testrail.com](https://support.testrail.com/hc/en-us/articles/54288720497940-TestRail-10-9-0-Default-1032))

That change is useful for organizations connecting TestRail to CI systems, engineering dashboards, data warehouses, or custom release portals. Smaller payloads reduce the work required by scheduled synchronization, while the timestamp gives downstream systems a clear signal that new execution activity changed a run.

AI-generated tests become visible to integrations

TestRail 10.9 adds is_ai_generated and is_ai_automated flags to API responses for test cases generated or automated using AI. Teams can identify those assets in code instead of depending on naming conventions or manual labels. ([support.testrail.com](https://support.testrail.com/hc/en-us/articles/54288720497940-TestRail-10-9-0-Default-1032))

The flags are not a governance system on their own, but they provide the data one would need to build it. QA leaders can use them to compare AI-assisted and human-authored cases, send generated tests through additional review, or track whether those cases are maintained and executed regularly.

The release also exposes test-case version information through several API methods, including get_case, add_case, get_run, and add_run. Integrations can now access version data that was previously available only through the TestRail interface.

Automatic user deactivation adds an access-control safeguard

Administrators can configure TestRail to deactivate users automatically after a chosen period of inactivity. The setting includes an inactivity threshold and a schedule for how often the process runs. It is available under Admin > Site Settings > Application. ([support.testrail.com](https://support.testrail.com/hc/en-us/articles/54288720497940-TestRail-10-9-0-Default-1032))

For enterprise QA teams, this is an access-control measure, not just an administrative convenience. Stale accounts can add license costs, complicate access reviews, and leave former contributors attached to sensitive test data. Before enabling a strict threshold, teams should decide how inactivity applies to occasional release participants, auditors, and service accounts.

What QA teams should check before upgrading

• Review API clients: Find scripts that reconstruct runs or plans through multiple calls and see whether the new rerun and case-addition endpoints can replace them.
• Update synchronization jobs: Test the extended updated_after filters and verify that result changes are captured.
• Extend reporting: Decide whether AI-generated and AI-automated flags belong in quality dashboards or approval workflows.
• Plan user deactivation carefully: Audit inactive accounts first, then choose a threshold that will not remove legitimate occasional users.
• Run regression checks: The release includes 44 listed fixes covering exports, dashboards, API responses, reports, attachments, and test-run behavior.

TestRail 10.9.0 is not a redesign, and it does not need to be. Its value is in the connections between test management and the rest of the delivery toolchain. For teams keeping test repositories in sync with fast-moving CI pipelines, the new APIs and metadata fields should matter more over time than another isolated authoring feature.