Is it safe to store a trigger key as a CI secret?

Yes. Store it in your CI secret store, never in your repository. A trigger key is scoped to one project, but treat it like any other credential and revoke it from your project settings if it's exposed.

Can I integrate results with my existing CI reporting?

Yes. Export results as JUnit XML (download it with a personal access token, since a trigger key only works on /api/trigger) and feed them into the same reporters and PR annotations you already use.

Running tests in CI/CD

Trigger runs from any CI with a token, export JUnit XML for your pipeline, and schedule recurring runs.

Generated tests are only useful if they run where your other tests run. Validate.QA gives you three ways to put them in your delivery pipeline: trigger keys, JUnit XML results, and schedules.

Trigger a run from CI

Create a trigger key (prefix tk_) in your project settings under Integrations → CI/CD and call the trigger endpoint from any CI job. By default the endpoint runs your active tests, optionally filtered by tags; suite mode instead runs the regression suite in a connected GitHub framework repo and needs that repo set up in Settings first. A trigger key is scoped to one project, but it is still a credential: keep it in your CI secret store and revoke it if it's exposed.

Kick off a run from a CI job

GitHub Actions

.github/workflows/validate-qa.yml

JUnit XML for your pipeline

Results are available as JUnit XML, so your existing CI test reporters, dashboards, and pull-request annotations work without any custom glue.

Download the file with a personal access token (pat_), not a trigger key. Create the token in your project settings under Integrations → MCP; it is bound to that project, so send it as the Bearer token and nothing else. A trigger key (tk_) only works on the /api/trigger endpoints and gets a 403 here, so a leaked CI key can only start runs and check their status under /api/trigger; it cannot download reports or reach anything else. Keep the token in your CI secret store too.

The file holds the project's latest result for each test over the last 7 days. Add ?days=N (1 to 365) to change the window, or ?framework=PLAYWRIGHT or ?framework=APPIUM to narrow it. There is no per-run filter, so download it after your run has finished (poll /api/trigger/run/:id/status with the trigger key until its status is passed, failed or error).

Download the JUnit XML

Scheduled runs

Beyond CI triggers, you can schedule recurring runs (from hourly to weekly) so a suite keeps watching production or staging on its own — with failures self-healing and real regressions surfaced as bugs.

Open Running tests in CI/CD · Get Started Free