API Reference

Fetches comprehensive information about Actions within your project. This endpoint supports:

• Pagination: Control response size with configurable page numbers and sizes (max 25 items per page)
• Flexible Filtering: Filter by specific Action IDs
• Optional Detailed Information: Selectively include Action Custom fields
• User-Specific Version View: Results reflect the requesting user’s current version of the entities.

Retrieves the referencing Actions and Scenarios associated with the provided Action IDs. A maximum of 25 Action IDs can be processed per request.

Returns a paginated list of application environments configured for the given Project.

Creates a new application environment under the specified Project.

Updates the name or description of an existing app environment.

Delete an existing App Environment in the specified Project.

Returns a paginated list of run properties configured for the current project.

Encrypts the provided input string and returns the encrypted value.

Creates a new run property for the specified project.

Fetches the activity history of Scenarios and Actions in a project using a stateless cursor-based approach. Designed for clients who need to track every create, update and delete operation on Scenarios and Actions, without missing or duplicating records. ### Call patterns Initial call (no cursor) Omit the cursor field and supply the filters. activityAfter, activityBefore, entityTypes and activityTypes are required. The server returns the first page of activity within the date range and freezes the filters into an opaque cursor token returned as nextCursor. Subsequent calls (with cursor) Pass only the cursor field from the previous response's nextCursor. Do not include any filters or dates; they are already frozen inside the cursor. To change filters, make a fresh initial call without a cursor. ### Polling

• hasMore: true — a full page was returned. Call again immediately with nextCursor to retrieve the next page.
• hasMore: false — all matching activity has been delivered.
• Retrieving newer activity — activity recorded after the initial call is not included in the current cursor. To retrieve recent activity, make a fresh initial call.

### Request fields

• actorEmails (optional) — list of email addresses of the users whose activity is to be retrieved. Matching is case-insensitive. If omitted or empty, activity of all users is returned. Email addresses that do not match any user return no records.
• entityTypes (required) — list of entity types to include. Supported values: ACTION, AUTO_SCENARIO, MANUAL_SCENARIO.
• activityTypes (required) — list of activity types to include. Supported values: CREATE, UPDATE, DELETE. Check-in, check-out and changes to entity are reported as UPDATE.
• activityAfter (required) — start of the time range (inclusive). Refer to the Date rules section.
• activityBefore (required) — end of the time range (exclusive). Refer to the Date rules section.
• limit (optional) — maximum number of records per page. Defaults to 100; values above 1000 are reduced to 1000.
• cursor — the nextCursor value from the previous response. Omit on the initial call. When a cursor is sent, all other fields must be omitted.

### Date rules

• Accepted format: ISO 8601 with an explicit UTC offset, e.g. 2026-06-01T00:00:00Z.
• activityAfter is inclusive; activityBefore is exclusive.
• activityAfter cannot be in the future.
• activityAfter cannot be older than 1 year.
• If activityBefore is in the future, it is silently clamped to now.
• activityBefore must be after activityAfter (after clamping).
• The window between activityAfter and activityBefore must not exceed 90 days.

### Ordering and safe upper bound Results are returned in descending order of when they were recorded, most recent first. A 5-second lag is applied to the upper time bound so that in-flight transactions have time to commit before they are read, preventing gaps in the results. ### Access Tenant admins and users with a role in the project can access this API.

Updates the name of an existing run property identified by its PID.

This API retrieves list of all template jobs that have been created and associated with a specific project.

Returns a user-wise summary of test case status updates for the specified manual test run. This helps identify which users updated which test cases during the run.

Creates a recurring test job template that automatically triggers executions based on the specified recurrence rules.

Triggers an immediate execution of a Scenario or Test Suite using the provided job configuration. The job is queued and starts running as soon as a suitable agent becomes available.

Creates a reusable job template that stores execution configuration for a Scenario or Test Suite. The executions can be triggered on demand using this job template Id

Creates a new job run using the configuration stored in the specified job template. Optional run properties can be overridden for this execution.

Fetches comprehensive information about test Scenarios within your project. This endpoint supports:

• Pagination: Control response size with configurable page numbers and sizes (max 25 items per page)
• Flexible Filtering: Filter by specific Scenario IDs or requirement traceability keys
• Optional Detailed Information: Selectively include additional details such as custom fields, step details, requirement traceability, and scenario traceability in the response
• User-Specific Version View: Results reflect the requesting user's current version of the entities.

Updates requirement traceability and status for multiple Scenarios.

Returns a paginated list of all projects available within the tenant.

Create a new project in the Tenant. Project name must adhere to the following criteria: 1. Must always start with an alphabetic character 2. Maximum length of 256 characters 3. Only letters, digits, spaces, and underscores allowed

Creates a new project by cloning configuration from an existing project.

Fetches tenant-level audit log entries using a stateless cursor-based approach. Designed for clients that need to continuously stream or replay audit activity without missing or duplicating records. ## Call patterns ### Initial call (no cursor) Omit the cursor field and supply optional filters. The server freezes those filters into an opaque cursor token returned as nextCursor.

• Open-tail stream (createdAfter only, no createdBefore): each subsequent poll advances the upper bound forward in real time, delivering new events as they are committed. The window from createdAfter to now must not exceed 90 days at the time of the initial call.
• Fixed window (createdAfter + createdBefore): the cursor exhausts once all matching rows in the range have been delivered (hasMore: false).
• Start from now (neither date supplied): stream begins at the current time, delivering only events that occur going forward.

### Subsequent calls (with cursor) Pass only the cursor field from the previous response's nextCursor. Do not include any filters or dates — they are already frozen inside the cursor. To change filters, start a new stream by making a fresh initial call without a cursor. ## Polling

• hasMore: true — a full page was returned; call again immediately with nextCursor to retrieve the next page.
• hasMore: false — the stream is caught up; wait before polling again, then retry with nextCursor.
• Always preserve nextCursor, even when data is empty. Discarding it loses your position in the stream.

## Date rules

• Accepted format: ISO 8601 with explicit UTC offset, e.g. 2026-06-01T00:00:00Z.
• createdAfter cannot be in the future.
• createdAfter cannot be older than 1 year (the audit log retention window).
• createdBefore requires createdAfter. If createdBefore is in the future it is silently clamped to now.
• createdBefore must be after createdAfter (after clamping).
• The window between createdAfter and createdBefore (or now for open tails) must not exceed 90 days.

## Ordering and safe upper bound Results are returned in ascending order by event ID (i.e. chronological order). A 5-second lag is applied to the upper time bound so that in-flight transactions have time to commit before the cursor reaches them, preventing gaps in the stream.

Updates the name and description of an existing project identified by its Pid.

This API configures Requirements Traceability Integration within the Project Configuration for a specified list of projects. It must be executed by a Tenant Admin to ensure access to all listed projects. Note: Any existing Requirements Traceability configuration will be overwritten. However, currently mapped tickets/stories from these integrations will be retained.

Retrieves the current status and results of a test job using its run PID. This includes the overall job status, the total number of test cases, and the counts of passed, failed, and not-run cases. You can monitor the status of an ongoing job using the API described below

Returns all subscriptions available in the tenant along with their associated license bundles and usage details.

Retrieve a list of all users in the tenant, including their assigned licenses and Project roles.

Creates a new user in the tenant and assigns licenses and project roles as specified.

Activates a User immediately or for a specified date range.

Deactivates the specified User

Assigns or updates license bundles for the specified user.

Deletes the specified User from the tenant.