TestRail 10.8.0 Default (1038)

Early Access release track date: 10-Sep-2026

Default release track date: 21-Sep-2026

TestRail 10.8 brings OAuth 2.0 authorization to the API, Centralized API Access Management, significantly more powerful querying capabilities for integration teams, and a round of targeted performance improvements for large-scale instances. Read on for the full picture.

πŸ” API OAuth 2.0 Authorization for Sembi MCP 

TestRail 10.8 introduces OAuth 2.0 authorization for the TestRail Cloud MCP, currently available in closed beta. This provides a secure, browser-based sign-in flow for connecting AI tools to TestRail, without requiring users to manually create or share API keys.

With OAuth 2.0, TestRail Cloud MCP users can:

  • Connect to TestRail through a secure browser-based sign-in flow, without manually generating API keys.
  • Review the permissions being requested before granting access, with clear scopes covering test data, file attachments, and profile information.
  • Authorize access through short-lived, scoped tokens, rather than relying on long-lived API keys.

OAuth 2.0 authorization is currently exclusive to the TestRail Cloud MCP integration and is not supported for general-purpose TestRail API integrations. Existing API keys remain fully supported for API authentication.

πŸ›‘οΈ API Management Dashboard

TestRail 10.8 also introduces a new API Management Dashboard in Site Settings, giving administrators centralized visibility and control over API access across their instance.

The dashboard brings together existing API keys and OAuth 2.0 tokens issued through Sembi MCP, allowing administrators to:

  • Monitor API access across the instance: View active API keys and OAuth 2.0 tokens in one place, including who created them, when they were last used, and how many API calls they've made.
  • Revoke access centrally: Immediately revoke API keys or tokens without relying on the users who created them.
  • Control who can create API credentials: Use role-based permissions to restrict which users can generate API access tokens.

This gives administrators greater visibility and control over API access, helping organizations manage integrations, review unused credentials, and reduce unnecessary access.

Site Settings > API > Access Management
The Access Management dashboard supports both existing API keys and OAuth 2.0 tokens, so organizations can benefit from centralized access management without changing their current authentication methods.

πŸ‘‰ Learn more about API Management dashboard.

πŸ”Œ API: Advanced Filtering, Incremental Sync & Field Selection

Integration teams and automation pipelines can now retrieve exactly the data they need β€” filtering, field scoping, and incremental sync all land in 10.8.

Incremental sync with updated_after

Add updated_after to any bulk list endpoint to fetch only records modified after a given timestamp. Sync jobs no longer need to re-fetch and diff your entire case library to find what changed.

GET /api/v2/get_cases/{project_id}&updated_after=1716249600

Applies to: get_cases, get_runs, get_results, get_results_for_case, get_results_for_run, get_plans, get_bdd, get_bdds

Richer server-side filtering

Major list endpoints now accept standard filter parameters: status_id, priority_id, section_id, assignedto_id, label_id, created_by, updated_by, and milestone_id, applied at the database level, not client-side.

Field selection

Add a fields parameter to bulk list endpoints to request only the fields your integration needs.

GET /api/v2/get_cases/{project_id}&fields=id,title,updated_on,priority_id

Especially useful for BI pipelines, reporting tools, and sync workflows that only need identifiers, timestamps, or status fields β€” not full case objects with all custom fields included.

πŸ”Œ API: Bulk Update Results

The new update_results endpoint updates multiple existing test results in a single API call.

POST /api/v2/update_results
  • Before 10.8, updating 500 results required 500 individual calls and careful rate-limit management. Now a handful of bulk requests handles the same workload.
  • Supports all standard and custom result fields - status_id, comment, elapsed, defects, assignedto_id, and any custom_* fields. Uses a partial success model: valid updates are applied; invalid ones fail individually with clear error detail so your integration can identify and retry only the affected records.
  • Common use cases: post-processing automation results, syncing external test frameworks, bulk defect assignment, correcting imported execution data.

The existing single-result update_result endpoint is unchanged.

⚑ Performance Improvements

Several targeted improvements to speed and stability for teams working at scale:

  • Dashboard charts now load from cached results by default and refresh in the background, preventing database pressure spikes when multiple users open dashboards simultaneously. A Refresh button lets you pull the latest data on demand.
  • Faster Bulk Case Updates in Dynamic Runs changes to dynamic run's filter is dramatically faster on large runs. Previously a single case edit on a run with thousands of tests could stall for over a minute β€” now that execution runs quickly without causing page delays.
  • API get_cases responses are faster for large suites, using batch data fetching to eliminate per-case database queries on list calls.
  • Project activity reporting is faster on large accounts, with improved database indexing on activity tracking queries.
  • Audit Trail Query Acceleration: Improved query efficiency when logging attachment metadata, preventing redundant database calls during bulk operations.

🐞 Fixes and Improvements (11)

  • TR-11152: Fixed an error that occurred when opening Pivotal Tracker projects from the TestRail plugin
  • TR-13381: Fixed the "No Access" system role disappearing from the default roles list
  • TR-14781: Fixed a Jira add-on configuration mismatch that occurred after updating integration project settings
  • TR-14956: Fixed the "Assigned To" field not appearing in printed test reports
  • TR-18368: Fixed custom case fields placed in the "Bottom" location disappearing after updating a test case
  • TR-20034: Fixed an issue where changes to a test plan could not be saved
  • TR-20211: Fixed the page automatically scrolling to the top after updating a test case status
  • TR-20368: Fixed the AI Test Case Generator failing during the "Generate Test Steps" stage
  • TR-20806: Fixed an issue preventing updates to user access permissions on the Users administration page
  • TR-21395: Fixed API-submitted test result comments losing Markdown formatting and line breaks when viewed in the UI
  • TR-21899: Fixed raw HTML tags displaying in test summary details for results submitted via the API
Was this article helpful?
0 out of 0 found this helpful