Vraelis
New verification
Skip to content
Product
OverviewSystemsGuaranteesVerificationsReviewRecords
Platform
IntegrationsDevelopersCommand line
Settings
OrganizationTeamPlansCreditsUsageLimitsBillingAccount
Back to site

Developers

Operate Vraelis from CI, an agent or a terminal: API keys, the command line, and signed webhooks. Launch verifications, gate the deploy on the decision, and read the evidence back.

Preflight access
Name your keys so you can tell them apart. The full key is shown once at creation. Keep keys server-side only, and rotate or revoke a key if it's ever exposed. Developer docs →
Gate your deploys from CI

Launch a verification against a preview build, wait for the decision, and ship only when it is Verified. Failed and Blocked stop the release; a run that merely finished is not a pass. One job, real-browser evidence, no dashboard to watch.

See the CI gate →
Developer overviewWebhook signing
Quickstart: gate a deploy from CI
shell
# 1. Submit the claim. Vraelis builds a plan and asks a person to review it before anything runs or is charged.
curl -X POST https://vraelis.com/api/v1/verifications \
  -H "X-Api-Key: YOUR_KEY" -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{ "deployment_url": "https://your-preview.example.com",
        "claim": "A customer can upgrade to Pro and still have it after signing back in" }'
# -> { "state": "review_required", "reviewed_plan_id": "rvp_...", "requirements": [...] }
# Nothing has run and nothing has been charged yet.

# 2. A person approves the plan: in the console's Review queue, or via the plan-approve endpoint.
#    Approval is a required, separate event. An API key cannot approve a plan that defines a guarantee.

# 3. Resubmit the SAME request with reviewed_plan_id to run exactly what was approved:
curl -X POST https://vraelis.com/api/v1/verifications \
  -H "X-Api-Key: YOUR_KEY" -H "Content-Type: application/json" \
  -d '{ "deployment_url": "https://your-preview.example.com",
        "claim": "A customer can upgrade to Pro and still have it after signing back in",
        "reviewed_plan_id": "rvp_..." }'
# -> { "verification_id": "vrf_...", "state": "running" }

# 4. Poll until a DECISION lands. While it is running the decision is null; keep polling.
curl https://vraelis.com/api/v1/verifications/VERIFICATION_ID -H "X-Api-Key: YOUR_KEY"
# -> { "state": "completed", "decision": "failed", "failures": [ { "title": "...", "reproduce": "..." } ] }

# 5. Gate on the DECISION, never the run state:
#      verified -> exit 0  (ship)     failed -> exit 1  (stop)     blocked -> exit 2  (stop)
#    A finished run is NOT a pass. "state":"completed" with "decision":"failed" must STOP the deploy.
#    Evidence (screenshots, traces) is fetched separately through a short-lived, owner-checked signed URL.

Verifications launched over the API draw on the same account balance as the web app. Auth via X-Api-Key or Authorization: Bearer.

Command line

The same verification the console runs, from a terminal or a CI job. It takes a deployment and a claim, and its exit code is the decision.

macOS and Linux
curl -fsS https://vraelis.com/install | sh
Windows, in PowerShell
irm https://vraelis.com/install.ps1 | iex

Node 18 or newer. No sudo, no admin, and neither script edits your PATH or your shell profile. Both are plain text at those URLs if you would rather read one first:curl https://vraelis.com/install orcurl https://vraelis.com/install.ps1. Or skip the installer entirely and run the file:curl -O https://vraelis.com/cli/vraelis.mjs, then node vraelis.mjs verify ...

then, on either
vraelis login
vraelis verify \
  --url https://your-preview.example.com \
  --claim "A customer can upgrade to Pro and still have access after signing back in"   --wait

On Windows, paste the key with a right-click. Ctrl+V does not work in every PowerShell window, and because login hides what you type, a paste that did nothing is indistinguishable from a key that was refused.

Direction, not built: a first verify call stops here today. The API now requires a person to approve the plan it derives before any run starts, and this CLI does not yet submit that approval or resubmit it, so --waitcannot reach a decision on its own. Approve the plan from the console's Review queue first.

--waitWait for the verdict. Without it the command prints the id and exits 0 immediately, which means started, not verified.
--jsonEmit one JSON object instead of human output. This is the mode for CI and for agents.
--repair-promptOn failure, print ONLY the repair prompt, ready to pipe into a coding agent.
--idempotency-keyReuse a key so a retry returns the original verification instead of starting, and paying for, a second one.
--timeoutHow long --wait waits before giving up. Default 900 seconds.
0Verified
1Failed
2Blocked, or could not run
ci
# In CI: gate the deploy on the DECISION, not on the command finishing.
curl -fsS https://vraelis.com/install | sh
vraelis verify --url "$PREVIEW_URL" --claim "$CLAIM" --wait --json > result.json
# exit 0 verified   exit 1 failed   exit 2 blocked, or could not run
#
# Blocked is not a pass. A run that merely finished is not a pass.
# Only exit 0 should ship.

# On a failure, hand the repair prompt straight to a coding agent:
vraelis verify --url "$PREVIEW_URL" --claim "$CLAIM" --wait --repair-prompt | claude -p

A CLI run spends the same credits as a console run and appears in Verifications and Records beside them. The key needs the Launch runs scope.

Webhooks

Get a signed verification.completed event pushed to your app the moment a verification finishes. Then pull results from the export endpoint. Docs →