QA.tech + CI/CD REST API
Every QA.tech test plan can be triggered through a standard REST API keyed off the plan's Short ID. That means any CI/CD system that can make an HTTP request works: Bitbucket Pipelines, Azure DevOps, CircleCI, Jenkins, and anything else. Application and environment URLs can be overridden per call to test the preview or staging build the pipeline just produced.
What you can do
- Plug QA.tech into whatever pipeline you already run
- Test a different preview environment on every build
- Gate deploys on smoke or critical-path plans
- Keep one test plan and point it at any URL
Set it up
Connecting CI/CD REST API
- 01
Create an API key in QA.tech and store it as a secret in your CI system.
- 02
Take the Short ID of the plan you want to trigger.
- 03
POST to the trigger endpoint from a pipeline step, overriding the application or environment URL for that build.
- 04
See our existing CI/CD workflow guide for patterns by pipeline vendor.
Full reference in the QA.tech docs.
Where teams use this
CI/CD REST API in practice
This is the catch-all: if your CI isn't GitHub or GitLab, this is how testing gets into the pipeline. The per-call URL override is the piece that makes multi-environment testing work, since each build's ephemeral preview gets tested without touching the plan definition. Most pipelines start by gating on a smoke plan and add a critical-path regression plan on release branches.
FAQ
Common questions
- Which CI systems are supported?
- Any system that can make an HTTP request. Bitbucket, Azure DevOps, CircleCI, and Jenkins are the common ones.
- Can one plan test many environments?
- Yes. Override the application/environment URL at trigger time.
Related integrations
GitLab
Next →Jira
Your team moves fast. Can your testing keep up?
QA.tech agents test your product autonomously, so moving fast never means shipping broken. See how it works in a 30-minute demo.