Skip to main content
The Chat API enables programmatic interaction with QA.tech’s AI Chat Assistant. Create conversations, send messages, start change reviews, and poll for responses—all via REST API. This is ideal for integrating QA.tech’s AI capabilities into your automation workflows, project management systems, or custom tooling.

​
When to Use This API

  • Automated test creation – Send context from your system to create tests without opening the QA.tech UI
  • PR/Change reviews – Automatically trigger AI-powered change reviews from CI/CD pipelines
  • Custom integrations – Build buttons or workflows in your project management tools that interact with QA.tech Chat
  • AI-assisted QA workflows – Let your automation systems communicate with QA.tech’s AI assistant
For simpler chat interactions, consider using the CLI chat command which handles polling automatically: qatech chat "Create a login test"

​
Authentication

All endpoints require Bearer token authentication. Create your API key in the QA.tech dashboard: Organization Settings → API Keys. The key is shown only once, at creation. See the API Introduction for details.

​
Endpoints

For full request, response, and error details, see the generated reference pages:

​
How Conversations Work

Chat processing is asynchronous. Creating a conversation or sending a message returns 202 Accepted immediately with an empty messages array — the assistant’s reply is not included. To read the reply and any test run it started, poll Get Chat Conversation until conversation status is completed, failed, or cancelled. We recommend polling every 2-5 seconds. Do not stop at the first assistant message with status: COMPLETED. Starting a test run ends that turn while the run continues in the background, so the conversation stays in_progress until the run finishes and the assistant writes its follow-up. When a run exists, runs[].shortId is the handle for Get Run (testCases: "all") and Get Run Test Case.
Assistant responses typically complete within 10-60 seconds depending on the complexity of the request. Test creation and execution may take several minutes.
You can target a specific application environment for the conversation — for example a preview deployment or an uploaded mobile build — by passing application overrides when creating it. See the Start Chat Conversation reference for the override format.

​
Change Reviews

Start Change Review Chat creates a conversation that initiates an AI-powered review of code changes. It supports two modes:
  • PR mode – Provide a pull request URL (GitHub or GitLab) and QA.tech fetches the changes
  • Raw changes mode – Provide a change description and a git diff directly, useful when the changes are not in a hosted PR
Both modes accept optional extra context to help the AI understand the changes, and take application overrides specifying which environment to review against.

​
Starting Before the Preview Is Deployed

For GitHub pull requests, call Prepare Change Review (POST /v1/chat/change-review/prepare) as soon as the PR opens or gets a new commit. It takes the pull request URL and the same optional fields as PR mode (including commitHash), but no applicationOverrides. The agent reads the change and creates the tests it plans to run without running them. Once the preview is up, send the usual change review request with applicationOverrides and the same commitHash: QA.tech treats it as the deployment being ready and the waiting review runs its tests there, in the same conversation. Without a prepared review, that request runs a full review as usual. A prepare request for a head commit that already has a review in the conversation does nothing and returns that conversation. If PR triage skipped that commit, the change review request does nothing either, unless it sends triage.enabled: false or someone requested a review with @qa.tech. A new commit is triaged again when you pass its commitHash. See the Change Review Action workflow for the GitHub Actions setup. For GitHub pull requests (mode: "pr", vcsProviderId: "github"), an explicit change-review request also creates or updates the QA.tech / PR Review check on the PR. This applies even when Auto-run on PRs is disabled in the GitHub App integration. See PR Review check on GitHub. PR mode also accepts optional postMerge options (enabled, and optional prompt). When set, they override the GitHub App integration post-merge settings for that PR after it merges. See Post-merge agent. For GitHub pull requests, PR mode also accepts optional triage options (enabled, prompt). By default, the review follows the GitHub App integration PR Triage toggle and prompt and may be skipped. enabled: true allows a skip even when the toggle is off, and enabled: false always runs the review. prompt (up to 4000 characters) replaces the integration PR triage prompt for this review. See PR triage. PR mode and prepare also accept disableReviewComments. Set it to true when you do not want the agent to post its review comments on the pull request or merge request, for example while evaluating QA.tech. Every pull request is still reviewed: the review is stored in QA.tech and shown in the conversation and on the pull request page, and on GitHub the QA.tech / PR Review check is still reported. The setting is stored on the review conversation, so later reviews of the same pull request stay silent until a request sends disableReviewComments: false. Omit it to keep the conversation’s current setting; comments are posted by default.

​
Attributing a Review to a Commit

Both modes accept the same optional git fields as Start Run: branch, commitHash, commitMessage, actor, and repository. Populate them from your CI context so the runs the review starts show the branch and commit in the dashboard, and so list_runs can filter them by branch or commitHash. In PR mode, commitHash also selects which commit prepare, triage, and review apply to. QA.tech loads review state (awaiting deployment, triage skip, repeat prepare) for that SHA. When commitHash differs from the head commit stored on the pull request row, QA.tech updates the stored head to match — use this from GitHub Actions so a fast CI job does not inherit triage or skip state from an older commit before webhooks catch up. On pull_request workflows, pass commitHash: github.event.pull_request.head.sha on both prepare and review calls. The GitHub App path already reads the head SHA from the webhook payload; only the API and Action flows need you to send it explicitly today. When git fields are omitted, QA.tech falls back to the head commit recorded for the pull request. Send them explicitly when the deployment you are reviewing was built from a different commit, or whenever CI may run before that row is updated.