QA TOUCH + API

Connect your tools to QA Touch with the QA Touch API

Send two headers with each request to create, view and update requirements, test cases, test runs and issues, or to send automation results to a test run.

Setup: an API key, plus domain and api-token headers

QA Touch

How it works Setup guide

When a ready-made integration doesn't exist, the API fills the gap.

The QA Touch API is how your own scripts, pipelines and internal tools read from and write to QA Touch. You decide what moves, and when.

Problem: Test data is updated by hand in more than one tool.

With the integration: A script calls the API and updates QA Touch for you.
Problem: Automation results stay in the framework that produced them.

With the integration: One call updates the status of several test cases in a test run.
Problem: Reporting needs data from QA Touch and other platforms.

With the integration: Pull QA Touch data into your own reports alongside the rest.

QA Touch

Test run

PassedLogin with valid user

FailedApply discount code

Your script

API request

POST runresult/updatestatus

Illustrative sample data. Names and results are examples.

What the API gives you

Five capabilities drawn from the QA Touch API integration page and QA Touch’s own API examples.

Two headers to authenticate

Every endpoint needs a couple of headers: your QA Touch domain and your API token. There is no other credential in the examples.

domainapi-token

Core modules, by API

Create, view and update requirements, test cases, test runs and issues, the key modules of your testing workflow.

Automation results into a run

One call updates the status of several test cases in a test run, sending the project, test run and a list of cases with their statuses.

Paginated lists

Endpoints that return more than 50 rows are paginated by default. Add the page parameter to ask for the next set.

Your own automation

Tailor integrations to your workflow, automate repetitive tasks, and combine QA Touch data with other platforms for reporting.

From API key to a request that changes QA Touch

Step through the flow. The snippets are schematic, built from the endpoints and headers in QA Touch’s examples.

QA Touch your profile

Generate the key in your profile

The key is created in your QA Touch profile, and API access must be enabled. QA Touch's materials word the menu path slightly differently, so follow the labels on your screen.

ProfileGeneral settings

API key

••••••••••••••••

Your code request headers

Send domain and api-token

Add both headers to every request. The domain is your QA Touch domain, and the token is the API key you generated.

HeadersEvery request

domain: your-domain api-token: your-api-token

Your code GET

List your projects

A good first call is the projects list. QA Touch's examples use this base URL and endpoint.

RequestGET

GET https://api.qatouch.com/api/v1/getAllProjects

Your code page parameter

Ask for the next page

Lists with more than 50 rows are paginated by default. Add page to get the next set, for example the second page.

RequestGET

GET https://api.qatouch.com/api/v1/getAllProjects?page=2

Your code POST QA Touch test run

Update several cases at once

Send the project key, the test run key and a list of cases with their statuses. The Go example passes these as query parameters.

RequestPOST

POST https://api.qatouch.com/api/v1/runresult/updatestatus/multiple project = PROJECT_KEY test_run = TEST_RUN_KEY cases = {"0": {"case": "CASE_KEY", "status": STATUS}}

QA Touch's example doesn't define what each numeric status value means. Check the API reference.

Illustrative values. Replace them with your own keys.

What changes for your QA team

Less hand-keyed data, and tools that talk to each other on your terms.

Fewer manual updates

Routine updates move to scripts, which cuts the time spent keying data and the mistakes that come with it.

Works with tools you already run

Connect QA Touch to your existing frameworks and internal systems, even where no packaged integration exists.

Results where the team reports

Automation outcomes land in the same test run as manual testing, so reviewers see one picture.

Reports built your way

Combine QA Touch data with data from other platforms for the analysis your team actually needs.

Who uses it, and for what

Choose a role to see a scenario the API supports.

Other teams want to script against QA Touch

You need to hand out access safely.

What they do

Confirm API access is available on your plan.
Generate an API key from the profile.
Share the domain and token only with the people building the integration.

Result: the builders have the two values every request needs.

Your framework has no QA Touch plugin

You still want its results in a test run.

What they do

Collect the case keys and outcomes after a run.
Post them with the multi-case update endpoint.
Open the test run to confirm the statuses.

Result: automated outcomes sit in the test run.

An internal tool should talk to QA Touch

You are building the connection.

What they do

Start with the projects list to confirm the headers work.
Use the API reference to find the endpoints for requirements, test cases, test runs or issues.
Page through long lists with the page parameter.

Result: your tool can read and update QA Touch data.

Reporting spans several platforms

The data you need isn't all in QA Touch.

What they do

Ask the team to pull QA Touch data through the API.
Combine it with data from the other platforms.
Review the combined picture.

Result: analysis built from every source, not one tool.

Set it up in four parts

These steps follow QA Touch’s API reference and the examples in its help and demo material.

Before you start

A QA Touch account with API access enabled.
Your QA Touch domain.
Something that can send HTTP requests with custom headers.

This page shows the endpoints used in QA Touch’s own examples. The full endpoint list, parameters, status values and error codes are in the API reference. Treat the API token as a secret and keep it out of version control.

Open your QA Touch profile and find the option to generate an API key.
The demo README names it Generate API Key under General settings. The Playwright guide calls the screen My Profile.
Make sure API access is enabled for your account.

Send the domain header with your QA Touch domain.
Send the api-token header with the API key.
Use the base URL https://api.qatouch.com/api/v1.

Send GET /getAllProjects to list your projects.
For more than 50 rows, add ?page=2 and so on.

Send POST /runresult/updatestatus/multiple.
Pass project, test_run and cases, a JSON object of case keys and statuses.
Open the test run in QA Touch to check the result.

Prefer a ready-made reporter for your framework?

Questions about the QA Touch API

Answers are based on the QA Touch API integration page and QA Touch’s own API examples.

What can I do with the QA Touch API?

Create, view and update requirements, test cases, test runs and issues, and send automation results to a test run. The API reference lists every endpoint.

How do I authenticate?

Send two headers with every request: domain, with your QA Touch domain, and api-token, with your API key.

How do I get an API key?

Generate it from your QA Touch profile. QA Touch’s materials describe the path in slightly different words, such as My Profile or Edit profile under General settings, and API access must be enabled.

Which plans include the API?

QA Touch’s API demo README says the API is a premium feature for Professional and Enterprise users. Confirm current plan details on the pricing page.

What is the base URL?

QA Touch’s examples use https://api.qatouch.com/api/v1, for example GET /getAllProjects.

How are long lists handled?

Endpoints that return more than 50 rows are paginated by default. Add the page parameter, such as page=2, to get the next set.

How do I send automation results?

POST to /runresult/updatestatus/multiple with the project key, the test run key and the cases with their statuses. For common frameworks, QA Touch also offers ready-made reporters and plugins.