Integrate Validate.QA Into Any CI Pipeline
Trigger API with tk_ bearer tokens, webhook notifications, auto-heal flag, and a copy-paste GitHub Actions template. QA that plugs into the CI you already have.
Every QA tool promises "CI/CD integration." Most of them mean "we have a REST API you can figure out." That is not integration. That is a burden shifted. Real integration is a documented endpoint, a stable auth story, and a templated workflow you can paste into a GitHub Actions file and have working in five minutes.
Validate.QA was built around the assumption that your CI pipeline is the source of truth for when tests should run, not our dashboard. You already have GitHub Actions, GitLab CI, CircleCI, Buildkite, or Jenkins. You already have a deploy script. Adding Validate.QA should be one HTTP call and one secret, not a weekend of plumbing. This post walks through the trigger API, webhook notifications, and auto-heal flags that make that true.
You will see exactly what the API expects, how batch-mode and suite-mode differ, how to wire Slack or Discord notifications, and a copy-paste GitHub Actions template you can drop into any repo. The goal by the end is that your next deploy triggers your regression suite automatically, results land in Slack, and nobody has to touch the Validate.QA dashboard.
Trigger Keys - The tk_ Token System
Everything starts with a tk_-prefixed trigger key. Trigger keys are narrowly scoped auth tokens designed for one thing: kicking off test runs from external systems. They are not user tokens. They cannot read your dashboard, view reports, modify tests, or manage schedules. They can only trigger runs on the project they were created for. If one leaks into a public repo, an attacker can run your tests - annoying, but not catastrophic.
To create one, go to Project Settings > Trigger Keys and click New Trigger Key. Give it a name that describes its purpose ("github-actions-main", "staging-deploy-hook"). The server generates a random token, hashes it with SHA-256, and shows the plaintext exactly once. Copy it immediately into your CI secrets store - you cannot retrieve it later. If you lose it, revoke and regenerate.
Every trigger key has metadata attached. You will see the last time it was used, the IP that used it, the number of runs triggered this month, and a soft-delete flag for instant revocation. If you need to rotate, hit Revoke, create a new one, and update the secret in your CI. There is no token-expiration mechanic by design - CI secrets that silently expire are a much bigger outage risk than a long-lived but narrowly-scoped token.
Topics: CI/CD, Webhooks, GitHub Actions, Integration.
Read the full article · Get Started Free