Skip to main content

CI/CD Integration

Any run can be triggered remotely over HTTP, from a GitHub Actions workflow, a Vercel deploy hook, a Fly.io release command, or any other pipeline that can make an HTTP request after a deploy, so you can run the same scenario automatically every time you ship, without opening VeriWasp and clicking Re-run by hand.

Finding your trigger URL​

On the private run detail page (/runs/{id}) for any run, there's a collapsible Trigger from CI/CD panel showing a ready-to-copy command:

curl -X POST https://veriwasp.com/api/trigger/{token}

Click Copy to grab it exactly as shown. Every run has its own unique token, generated the moment the run is created (even a draft has one already, in case you want to wire up the pipeline before ever running it manually the first time).

:::caution This URL is a secret Anyone with this exact URL can trigger runs on your account, spending your credits each time. Treat it the way you'd treat an API key: store it in your CI provider's encrypted secrets store (GitHub Actions secrets, for instance), never commit it to a repository, and never post it anywhere public. It is not shown anywhere on the run's public shareable report, only on the private, logged-in run detail page. :::

What happens on trigger​

A POST to /api/trigger/{token}:

  1. Looks up the run that owns that trigger token.
  2. Clones it into a brand-new run (same target URL, viewport, Chaos Mode setting, and steps, with its own fresh ID, share slug, and trigger token) and immediately queues it for execution. This is the exact same clone-and-trigger logic the Re-run button uses; see Re-running a Test for the underlying mechanics.
  3. Deducts credits from your account the same way any other run start does (1 for a normal run, 3 with Chaos Mode). If your balance is too low, the request fails with an HTTP 402 Payment Required response instead of silently queuing.
  4. Responds immediately (it doesn't wait for the run to finish) with a JSON body:
{
  "run_id": "3f1e2c9a-...",
  "status": "queued",
  "report_url": "https://veriwasp.com/r/f8a2c1"
}

The report_url in that response is the fastest way to link straight to the new run's live report from within your pipeline's own logs or a deploy notification, for instance posting it into a Slack message alongside a "deploy succeeded" notice.

Using the original run's trigger URL, every time​

Because triggering clones the run rather than re-executing the exact run row the token belongs to, you always use the same original run's trigger URL every time. You don't need to fetch a new token after each deploy. Each new triggered run gets its own new ID and its own new token, but those new tokens aren't the ones you use going forward; keep using the original one you copied from the run detail page.

Rate limits​

Trigger requests are rate-limited per token: up to 30 requests immediately in a burst, refilling at a rate of 1 additional request every 2 minutes after that. This is generous enough for normal CI usage (triggering on every merge to main, for instance) while still preventing a misconfigured pipeline or a leaked token from being used to drain your credit balance in a tight loop. A request beyond the limit gets an HTTP 429 Too Many Requests response rather than being queued.

A GitHub Actions example​

name: Post-deploy playtest
on:
  deployment_status:
jobs:
  playtest:
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - name: Trigger VeriWasp run
        run: curl -X POST "${{ secrets.VERIWASP_TRIGGER_URL }}"

Store the full https://veriwasp.com/api/trigger/{token} URL as a single GitHub Actions secret (VERIWASP_TRIGGER_URL) rather than splitting the token out separately. There's no reason to reconstruct the URL at runtime, and keeping it as one opaque secret value minimizes how much of it is ever visible in workflow logs.