Where does Karate put its HTML report?

`target/karate-reports/karate-summary.html`, with a page per feature next to it. Publish the directory so the per-feature pages and their request/response logs come along.

Why publish an API test report?

Because Karate's report contains the actual request and response bodies for each step, which is the single most useful thing to hand to whoever owns the API. That evidence is worth a URL rather than a CI artifact that expires.

Should request bodies be published?

Only as carefully as you would share them anywhere. Karate logs what it sent and received, tokens included unless you configure `karate.configure('logPrettyResponse')` and header masking. Reports are private by default; keep API-test reports team-visible at most.

How do I see whether a scenario is newly failing?

PATCH the same report id per suite. One URL with a revision per run makes the comparison direct, instead of opening two artifact downloads side by side.

Does this work for Karate's performance mode too?

The Gatling-based performance reports are separate HTML output and publish the same way — many teams keep a functional report and a performance report as two report ids.

Share a Karate report

Karate's report has the one thing every API test argument needs: the request that was sent and the response that came back, verbatim, for the step that failed. Nobody has to reconstruct it or be believed about it.

Which makes it strange that the usual way this evidence travels is someone pasting four lines of it into a channel.

Publish it

mvn test -Dtest=ApiRunner || true

curl -fsS -X PATCH \
  "https://commareports.com/api/v1/reports/$COMMA_REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html target/karate-reports/karate-summary.html \
        --arg title "API suite — $ENVIRONMENT — build $BUILD_NUMBER" \
        '{title: $title, html: $html}')"

Or drag target/karate-reports/ into the app so the per-feature pages upload as assets and the summary's links to them keep working — publishing the summary alone gives you a page whose links go nowhere.

|| true keeps the publish running on a red build. One report id per suite or per environment; PATCH appends a revision per run.

Mind what is in the log

Karate records request and response bodies, headers included. That is the value and also the caution: an auth header or a PII-bearing response body ends up in the report. Reports are private by default and access is per report — keep API-test reports team-visible at most. See the sharing model, and use a scoped token with reports:write only for the publish step.

What the URL changes

The API owner gets the evidence, not a summary of it. Threads anchor to the scenario. See commenting on HTML.
Environment-by-environment history. Staging and prod smoke runs as separate report ids with separate trends.
Readable without a Maven install — or a CI login.
Scheduled smoke runs. A routine runs the suite on a cron and refreshes the report.

Limits

Entry HTML: 5 MB. Assets: 25 MB per file, 250 MB and 500 files total — a suite with hundreds of features approaches the file count; publish per feature group when it does.
Scripts run, sandboxed: allow-scripts, no allow-same-origin.
60 requests/minute per token.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Create your first report →

Cucumber reports · Serenity
Newman / Postman — the other API run worth a URL
Gatling · Publish from CI