Is the trigger token safe to commit as a CI secret?

Trigger tokens can only start runs — they can't read or change project data — so they're appropriate to store as a CI secret. Treat them like any other secret and rotate if exposed.

Can I integrate results with my existing CI reporting?

Yes. Export results as JUnit XML 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 tokens, JUnit export, and schedules.

Trigger a run from CI

Create a trigger token (prefix tk_) in your project settings and call the trigger endpoint from any CI job. Trigger tokens can only start runs — they can't read or modify project data — so they're safe to store as a CI secret.

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.

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