How do I share a Newman HTML report with my team?

Run the collection with a JSON reporter, render a digest of the run, and publish it to Comma with one curl. Teammates open a URL showing each request, its status code, assertion results and response time — instead of receiving newman-report.html as an attachment.

Does newman-reporter-htmlextra output render inside Comma?

Yes. Comma stores report HTML verbatim and renders it inside an iframe with sandbox="allow-scripts" and no allow-same-origin, so htmlextra's collapsible request panels, filters and search keep working. Publish report.html directly, or publish a failures-first digest built from the JSON reporter when you want a shorter surface to review.

How do I keep one URL across runs of the same collection?

Create the report once, store its id, and PATCH it on every run. Each run appends a revision at the same URL, so the link in your runbook stays valid and any two runs can be diffed — useful when a contract test starts failing and you need to know when it changed.

Can I publish runs against multiple environments?

One report per collection-and-environment pair is the shape that reads best: staging and production runs each keep their own URL and their own revision history, so a diff compares like with like.

Is this useful for API monitoring, not just CI?

Yes. A scheduled collection run that PATCHes the same report gives you a always-current status page for the API contract, with the previous runs kept as revisions and a webhook that announces each new one.

Share a Newman / Postman run report

Newman runs the collection and prints a summary table. Add newman-reporter-htmlextra and you get a genuinely nice HTML report — per request, per assertion, with response bodies and timings.

Then it sits at newman/report.html on whichever machine ran it. In CI it's an artifact zip; locally it's a file you open with file:// and attach to a Slack thread. The QA engineer who wants to show a backend developer that POST /orders returns 200 with an empty body has no link to send.

The pattern

Run with the JSON reporter so the pipeline has structured output:

newman run collection.json \
  -e environments/staging.json \
  --reporters cli,json,htmlextra \
  --reporter-json-export newman/run.json \
  --reporter-htmlextra-export newman/report.html

Render run.json into a digest — request name, method, URL, status, assertion pass/fail with the failure message, response time — and publish it with a scoped token (reports:write only):

curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html newman/digest.html \
        --arg title "API contract — staging — $(date -u +%Y-%m-%d)" \
        '{title: $title, html: $html}')"

One report per collection-and-environment pair. PATCH on every run so the URL in the runbook never goes stale.

Publish the htmlextra file, or a digest — both work

htmlextra's output is an app: expandable panels, filter toggles, a search box. That's fine here. Comma stores report HTML verbatim and renders it in an iframe with sandbox="allow-scripts" and no allow-same-origin, so the report's own JavaScript runs — from an opaque origin, with no access to the app's DOM, cookies or storage. curl the file straight up and the controls still work.

A digest is still worth building when the collection is large, because a reviewer wants the failing requests, not all 200 of them:

Failures first, with the assertion message and the response body excerpt inline. Passing requests collapse into a count.
Attach the original. report.html and any large response captures go in as assets — 25 MB per file, 250 MB per report.
Redact before you publish. Collection runs carry real request and response bodies, and sometimes tokens in headers. Strip auth headers from the digest and keep the report team-visible rather than public — see the sharing model.

Comments on the request that failed

The digest renders with an anchored comment layer on top. QA highlights the row for POST /orders › expects 201 and pins a thread: "this started failing after the idempotency-key change — is the 200 intentional?" The backend developer answers on the thread, and it stays attached to that request as later runs append revisions.

When the same contract breaks again in two months, the previous conversation is on the page rather than in Slack scrollback. That mechanism is described in full in commenting on an HTML report.

Monitoring, not just CI

A collection run on a schedule is a contract monitor. Point a scheduled routine at it, or a cron in your own infrastructure, and PATCH the same report each time:

The report becomes an always-current status page for the API contract.
Previous runs stay as diffable revisions.
A webhook on revision.created announces each run into Slack or Discord — red runs stop being a thing someone has to notice.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history. Publish the next collection run and send the link.

Create your first report →

Share a Playwright report — the same shape, browser tests
Publish from CI — the general pipeline recipe
How to share an HTML report — the six properties a shared report needs