Create Test Case API

API endpoint for programmatically creating test cases

The Create Test Case API allows you to programmatically create new test cases for your project. Use this endpoint to import tests from external systems, generate tests dynamically based on code analysis or custom logic, or automate test creation as part of your CI/CD workflows. For more examples and integration ideas, see CI/CD Integration.

• Endpoint: POST /test-cases
• Authentication: Bearer token
• Content-Type: application/json
• Base URL: https://api.qa.tech/v1

Request Body

The request body must be a JSON object with the following fields:

Required Fields

Field	Type	Description
name	string	Test case name (1-80 characters)
goal	string	The goal/objective of the test case. Describes what the test should accomplish.
applicationShortId	string	Application short ID (prefixed, e.g. app_gXeBl2). Must belong to the project.

Optional Fields

Field	Type	Description
expectedResult	string	Expected result description. Additional context about what success looks like.
configShortIds	array of strings	Array of config short IDs (e.g. ["cfg_abc123"]). Configs are available to the test during execution.
scenarioShortId	string	Scenario short ID (e.g. scenario_abc123) if grouping tests into scenarios. Must belong to the project.
resumeFromDependencyProjectTestCaseId	string (UUID)	ID of a test case to resume browser state from (Resume From dependency). See Dependencies below.
waitForDependenciesProjectTestCaseIds	array of UUIDs	Array of test case IDs that must complete before this test runs (Wait For dependencies). See Dependencies below.

Short ID fields (applicationShortId, configShortIds, scenarioShortId) use prefixed format (e.g. app_gXeBl2, cfg_xyz789, scenario_abc123). Dependency fields (resumeFromDependencyProjectTestCaseId, waitForDependenciesProjectTestCaseIds) use UUIDs (project test case internal IDs).

Authentication

This endpoint requires Bearer token authentication. The project is inferred from the token. See API Introduction.

Test Dependencies in API

Test cases can depend on other test cases to control execution order and share browser state. Dependencies enable you to build test workflows where tests run in sequence, reuse expensive setup like authentication, and pass data between tests. The API supports two dependency types:

• Resume From: Continues the browser session from another test, preserving cookies, localStorage, and sessionStorage. Use this for sequential workflows that build on each other (e.g., login → create → edit).
• Wait For: Waits for other tests to complete before starting, but uses a fresh browser session. Use this when you need execution order and data passing but want isolated browser state.

For detailed information about how dependencies work, execution order, browser isolation, and multi-user testing scenarios, see Test Dependencies.

Resume From Dependency

The resumeFromDependencyProjectTestCaseId field creates a Resume From dependency. This allows your test to resume browser state from a previous test case, effectively continuing the browser session.

How it works:

• The test resumes browser state (cookies, localStorage, sessionStorage) from the dependency test
• Skips login/setup steps that were already completed
• Use case: Sequential tests that build on each other (e.g., login test → profile update test → logout test)

Example: A “Update Profile” test can resume from a “Login” test, skipping the login step and starting directly at the profile page.

Wait For Dependencies

The waitForDependenciesProjectTestCaseIds field creates Wait For dependencies. This ensures your test waits for one or more other tests to complete before starting execution.

How it works:

• The test waits for all specified dependency tests to complete successfully (status: COMPLETED, result: PASSED)
• If any dependency fails, the dependent test will not run
• Tests can run in parallel, but this test waits for all dependencies to pass
• Use case: Parallel setup tests, then sequential verification (e.g., setup test A and B run in parallel, verification test C waits for both to pass)

Example: A “Final Verification” test can wait for multiple setup tests to complete before running its checks.

Resume From vs Wait For

Feature	Resume From	Wait For
Purpose	Continue browser session	Wait for completion
Browser State	Resumes from dependency	Fresh browser session
Execution Order	Sequential (runs after dependency)	Parallel setup, sequential execution
Use Case	Multi-step flows in same session	Parallel setup, then verification
Number of Dependencies	Single test case	Multiple test cases

You can use both dependency types together. For example, a test can wait for multiple setup tests to complete, then resume browser state from one of them.

Response Format

Success Response (200)

{
  "success": true,
  "testCase": {
    "id": "550e8400-e29b-41d4-a716-446655440000",
    "name": "Login Test",
    "url": "https://app.qa.tech/p/project-slug/test-cases/550e8400-e29b-41d4-a716-446655440000/edit"
  }
}

The test case is created with generationStatus: 'GENERATING' and automatically undergoes a burn-in process to generate test steps. During burn-in, QA.tech executes the test against your application to discover and record the steps needed to accomplish your goal. Once burn-in completes, the test steps are saved and the test case status changes to COMPLETED.

Test cases created via API are disabled by default (isEnabled: false). Enable them in the QA.tech UI before they run in test plans.

Error Responses

Status	Description
400	Malformed body, missing required fields, validation failure, or invalid IDs. Response includes message.
401	Missing or invalid API key.
403	Invalid token or organization suspended.
404	Resource not found (project or referenced entity).
500	Server error during test creation.

Example Requests

Basic Test Case Creation

curl -X POST https://api.qa.tech/v1/test-cases \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -d '{
    "name": "Login Test",
    "goal": "Verify that users can log in successfully with valid credentials",
    "expectedResult": "User should be redirected to dashboard after successful login",
    "applicationShortId": "app_gXeBl2"
  }'

Test Case with Configurations

curl -X POST https://api.qa.tech/v1/test-cases \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -d '{
    "name": "Checkout Flow Test",
    "goal": "Complete a purchase from cart to order confirmation",
    "expectedResult": "Order should be placed successfully and confirmation email sent",
    "applicationShortId": "app_gXeBl2",
    "configShortIds": ["cfg_abc123", "cfg_xyz789"]
  }'

Test Case with Resume From Dependency

curl -X POST https://api.qa.tech/v1/test-cases \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -d '{
    "name": "Update Profile Test",
    "goal": "Update user profile information",
    "expectedResult": "Profile should be updated and changes reflected immediately",
    "applicationShortId": "app_gXeBl2",
    "resumeFromDependencyProjectTestCaseId": "a1b2c3d4-e5f6-4789-a012-3456789abcde"
  }'

This creates a test that will resume browser state from the login test (UUID of the dependency project test case).

Test Case with Wait For Dependencies

curl -X POST https://api.qa.tech/v1/test-cases \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -d '{
    "name": "Final Verification Test",
    "goal": "Verify all setup steps completed successfully",
    "expectedResult": "All setup tests passed and system is ready",
    "applicationShortId": "app_gXeBl2",
    "waitForDependenciesProjectTestCaseIds": [
      "a1b2c3d4-e5f6-4789-a012-3456789abcde",
      "b2c3d4e5-f6a7-4890-b123-456789abcdef"
    ]
  }'

This test will wait for both setup tests to complete successfully before starting execution.

CI/CD Integration

This API endpoint works with any CI/CD system. For platform-specific guides:

• CI/CD Integration Overview – Integration modes and patterns
• GitHub Actions – Official GitHub Action for running tests
• GitLab CI – GitLab CI/CD examples

Related Endpoints

• Start Run API – Trigger test execution after creating tests
• API Introduction – Authentication and ID reference