Add a Quality Gate to Your CI/CD Pipeline in 5 Minutes

You deploy to production. Something breaks. You find out from users — not your pipeline.

This is the gap between "tests pass in CI" and "the deployed site actually works." Static code analysis catches syntax issues, but who checks that your login flow still works after deploy? That your checkout page loads in under 3 seconds? That you haven't introduced an XSS vulnerability?

QuantumVerifi's quality gate fills this gap with a single HTTP call.

How It Works#

After your pipeline deploys to staging (or production), add one step:

Bash
Copy
1curl -X POST https://quantumverifi.com/api/v1/cicd/gate \
2  -H "X-API-Key: $QV_API_KEY" \
3  -H "Content-Type: application/json" \
4  -d '{
5    "target_url": "https://staging.your-app.com",
6    "min_grade": "C",
7    "max_age_minutes": 120
8  }'

The response tells your pipeline what to do:

What Gets Checked#

The quality gate doesn't just check one thing. The response includes a checks[] array breaking down every dimension:

• E2E Tests — Do critical user journeys work? Login, checkout, forms?
• Security — Any XSS, SQL injection, or critical vulnerabilities?
• Accessibility — WCAG compliance, screen reader support?
• Performance — Lighthouse scores, Core Web Vitals?

Critical security findings auto-fail regardless of overall grade. A site with grade B but an XSS vulnerability still gets blocked.

GitHub Actions#

YAML
Copy
1- name: QuantumVerifi Quality Gate
2  run: |
3    RESPONSE=$(curl -s -X POST https://quantumverifi.com/api/v1/cicd/gate \
4      -H "Content-Type: application/json" \
5      -H "X-API-Key: ${{ secrets.QV_API_KEY }}" \
6      -d '{
7        "target_url": "${{ env.DEPLOYED_URL }}",
8        "min_grade": "C"
9      }')
10    DECISION=$(echo "$RESPONSE" | jq -r '.decision')
11    if [ "$DECISION" != "pass" ]; then
12      echo "::error::Quality gate failed: $(echo $RESPONSE | jq -r '.message')"
13      exit 1
14    fi

Harness#

YAML
Copy
1- step:
2    type: Http
3    name: Quality Gate
4    spec:
5      url: https://quantumverifi.com/api/v1/cicd/gate
6      method: POST
7      headers:
8        - key: X-API-Key
9          value: <+secrets.getValue("quantumverifi_api_key")>
10      requestBody: |
11        {
12          "target_url": "<+pipeline.variables.target_url>",
13          "min_grade": "C"
14        }
15      assertion: >-
16        <+httpResponseCode> == 200 &&
17        <+json.select("decision", httpResponseBody)> == "pass"

What About Stale Data?#

The max_age_minutes parameter controls freshness. If the latest analysis is older than your threshold, you have two options:

1. Block (default) — the gate returns no_data with reason analysis_too_old
2. Auto-trigger — set trigger_new: true and the gate kicks off a fresh analysis, returning pending with a Retry-After header

The Bottom Line#

One HTTP call. Any CI/CD system. Your quality bar, enforced automatically.

The gate check itself is free — it reads existing analysis results. Only new analyses (via trigger_new) consume credits.

Head to Settings > Integrations to grab the snippet for your CI/CD system, or check the full API reference.