HTTP API · /api/v1

The website testing API: one call, a real browser, a JSON verdict

POST a URL, get back a graded QA report. The agent loop drives a real browser; plain code verifies the result. Anonymous, no card, OpenAPI-published.

Free audit — no signup, no card. The same run the API triggers.

We pointed this API at 49 Show HN launches: 78% had a critical bug on day one. See the audit of 49 Show HN launches.

Looking for an API to test your REST endpoints? That's Postman/ReqBin. This is an API that QA-tests a live website for you.

agent session
$ curl -sX POST https://prufa.dev/api/v1/audits \
-H 'Content-Type: application/json' \
-d '{"url": "https://yourapp.com"}'
→ 202 run_id a1b2c3d4 status queued
report_url https://prufa.dev/r/k7m2qx
 
$ curl -s .../reports/by-token/k7m2qx
✓ VERIFIED critical tracking.none_detected · / · 10:14:22Z
✓ VERIFIED warning security.missing_csp · /
· ADVISORY opinion hero CTA placement (not counted)
One POST returns a run_id and a report_url; a second fetch returns the JSON verdict — VERIFIED findings drive the grade, ADVISORY is labeled and counts toward nothing.

Is there an API that runs QA tests on a website?

You have CI, or an agent that just shipped a change, and you want one HTTP call that answers "is this page actually broken?" — not a status code, not a Lighthouse number, not a suite of expect() assertions you have to write and maintain first. Searching "website testing API" mostly returns tools for testing your APIs. That's the opposite of what you need.

Prufa is the inverse. You POST a URL; a managed agent loop opens a real browser, navigates the public pages, and records everything over CDP — every analytics beacon, console error, cookie, response code, and a DOM snapshot. Then plain, deterministic code grades the captured evidence against declarative specs. The LLM navigates; it never decides whether a tracking beacon is correct or a link is broken — captured traffic is asserted against a spec. Same input, same verdict. That separation is what makes an API verdict trustworthy enough to gate a deploy on. See how Prufa verifies a signup flow without letting the model grade the result.

The REST API is one of three ways to call the same engine. Coding agents reach it through the QA MCP server; from a terminal or CI script you can use the command-line QA tool; and you can always try it with no code at all via the free website audit.

How do I trigger a website test from a REST API?

Three calls: start the run, watch it stream, read the machine verdict. The model navigates; deterministic code decides what counts as broken.

  1. POST a URL

    POST /api/v1/audits with {"url": "https://yourapp.com"}. The anonymous audit needs no key and no card. You get 202 with a run_id, a status, an SSE events_url, and a report_url (/r/<share_token>).

  2. The agent drives a real browser

    The run goes to a worker. A real browser loads the public pages and captures network traffic, console output, cookies, and response codes. Progress streams over Server-Sent Events with replay until the terminal status: succeeded, failed, blocked, or timeout.

  3. Evidence keeps the score

    Fetch the JSON report. Six sections graded A–F — Works, Fast, Found, Measured, Accessible, Compliant — plus an ungraded Flows section. Counts and grades come from VERIFIED findings only; ADVISORY observations are labeled and excluded. No composite 0–100 score — we don't fake precision.

A website QA test in one API call

Real and copy-pasteable: trigger the run, then read the JSON verdict when the status is terminal.

bash
# 1. Trigger an audit — anonymous, no key, no card.
curl -sX POST https://prufa.dev/api/v1/audits \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: deploy-2026-07-01-7f3a' \
  -d '{"url": "https://yourapp.com"}'

# 202 Accepted
{
  "run_id": "a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d",
  "status": "queued",
  "events_url": "https://prufa.dev/api/audits/a1b2c3d4/events",
  "report_url": "https://prufa.dev/r/k7m2qx"
}

# 2. Read the machine verdict when status is terminal.
curl -s https://prufa.dev/api/v1/reports/by-token/k7m2qx

# report.json (abridged) — VERIFIED findings drive the grade; ADVISORY is labeled.
{
  "status": "succeeded",
  "sections": {
    "Measured": { "grade": "F", "critical": 1 },
    "Found":    { "grade": "C", "warning": 2 },
    "Works":    { "grade": "A" }
  },
  "findings": [
    {
      "tier": "verified",
      "severity": "critical",
      "check": "tracking.none_detected",
      "title": "No analytics events detected on any page",
      "evidence": "tracking.none_detected · / · 2026-07-01T10:14:22Z"
    },
    {
      "tier": "advisory",
      "severity": "info",
      "check": "advisory.analyze",
      "title": "Hero copy may bury the primary CTA",
      "note": "Opinion — not counted toward any grade."
    }
  ]
}

Auth. The anonymous audit needs no token. Persistent tools (flows, monitors, run history) use a workspace bearer token, Authorization: Bearer prk_..., self-provisioned by the agent as a free, no-card trial via prufa_setup_workspace (needs the human's email), or minted by a human in the dashboard for a paid workspace.

Idempotency. Every mutating endpoint accepts Idempotency-Key; a replay within 24h returns the original response without re-running — how we built it.

Spec. The full surface is at /api/v1/openapi.json with docs at /api/v1/docs.

What a JSON verdict actually contains

VERIFIED findings are machine-checked against captured evidence and drive every count and grade. ADVISORY observations are labeled opinion and counted toward nothing — shown separately, never mixed in.

Verified — machine-checked, evidence-backed

critical ✓ verified
No analytics events detected on any page
tracking.none_detected · / · 2026-07-01T10:14:22Z

Your product is shipping blind — no events fired across the public pages.

critical ✓ verified
Canonical points to a different host
seo.canonical_host_mismatch · /pricing · 2026-07-01T10:14:31Z

Search engines are told the real page lives somewhere else.

warning ✓ verified
No Content-Security-Policy header
security.missing_csp · / · 2026-07-01T10:14:25Z

Nothing constrains which scripts the page may load.

Advisory — labeled opinion, excluded from grades

opinion
Hero copy may bury the primary CTA

A judgment call, not a verified fact — excluded from every count and grade.

Straight answers before you wire it in

Isn't “website testing API” just an API-testing tool like Postman?

No — and we say so on the first screen. Postman, ReqBin and HTTPie test the HTTP endpoints you build. Prufa's API runs a browser QA audit on a website: you give it a URL, it returns broken links, dead analytics, console errors, consent state and layout breakage. If you want to assert on a JSON response shape, use Postman. If you want to know whether a page works, call this.

Can I trust a verdict that involves an LLM enough to gate a deploy?

The agent loop only navigates and drives the browser. Grades and severity counts are computed by deterministic code from captured evidence — the LLM never judges whether a finding is real, so the verdict is reproducible (regression-tested against a golden fixture site). LLM-judged observations ship as a separate, labeled ADVISORY tier and count toward nothing. Agentic testing vs scripted testing.

What does the API not do yet?

Honest limits: the free audit walks public pages, not authenticated flows — flows and monitors are paid-tier and require a card-first workspace. Prufa does not scan for exposed secrets. Full-auto discovery is gated, not a one-call feature. The evidence-gated AI-VERIFIED path currently lives in the Gremlin chaos modality, not the standard audit — in a standard audit the lone LLM check stays advisory.

Frequently asked questions

The questions developers and agents ask before they trigger a website test from code.

Is there an API to run QA tests on my website, not an API for testing APIs?

Yes — and this is the distinction that matters. Tools like Postman test your REST endpoints. Prufa's API does the opposite: you POST a URL and it drives a real browser through the page, captures network traffic, console errors, cookies and response codes, then returns a graded report. One call audits a live site. It is not an HTTP-request client; it is a QA run you trigger from code.

How do I trigger a website test from a REST API?

Send POST /api/v1/audits with {"url": "https://yourapp.com"}. The anonymous audit needs no key and no card. You get back 202 with a run_id, a status, an SSE events_url to stream progress, and a report_url of the form /r/<share_token>. Poll GET /api/v1/audits/{id} or read the live stream until status is succeeded, failed, blocked or timeout.

Can I get QA results as JSON, or only as an HTML report?

Both. Every report is rendered as shareable HTML for humans and as machine-readable JSON for agents. Fetch GET /api/v1/audits/{id}/report.json or GET /api/v1/reports/by-token/{share_token}. The JSON carries the six graded sections, per-finding severity (critical/warning/info), and the tier — VERIFIED (machine-checked) versus ADVISORY (LLM opinion, excluded from every count and grade).

Does the website testing API support idempotency keys and safe retries?

Yes. Every mutating endpoint accepts an Idempotency-Key header; a replay within 24 hours returns the original response without re-executing the run. This is a load-bearing contract: agents retry on network blips, so a duplicate POST with the same key never starts a second audit. The full surface is versioned under /api/v1 with an OpenAPI document at /api/v1/openapi.json and docs at /api/v1/docs — a contract we don't break without a new version.

Run your first website test with one API call

Try it from the browser first — same run the API triggers, no card. Then wire the POST into CI or hand it to your agent. Persistent flows and monitoring start on the paid tiers; see pricing.

or see pricing →