Can I share Applitools results with someone without a licence?

Not the Test Manager itself. Pull the failing checkpoints via the API and publish them as a page — the reader needs a browser and nothing else.

Why not just send the batch URL?

Because it prompts for a login, and the person you sent it to does not have one. Applitools seats go to QA and engineering; visual judgment usually lives with design and product.

Which checkpoints should the page include?

The unresolved ones. A batch can carry hundreds of passing checkpoints; the reviewer needs the handful that differ from baseline.

Does this change where baselines are accepted?

No. Accepting and rejecting stays in the Test Manager. The page is where the decision gets discussed by people who cannot open it.

Does Ultrafast Grid change anything?

Only in volume — one checkpoint becomes many browser and viewport combinations. Group them by checkpoint on the page or the reader loses the thread.

Share an Applitools Eyes result

Eyes flagged a layout shift on the checkout page across four viewports. The Test Manager shows it perfectly: baseline, checkpoint, the highlighted region, the whole history.

You paste the batch URL into the design channel and it asks everyone to log in.

Visual AI, human sign-off

Applitools is good at the hard part — deciding what counts as a meaningful visual difference rather than an anti-aliasing artifact. What it cannot decide is whether the meaningful difference was intended, and that answer lives with whoever owns the design.

That person has no Eyes licence, and provisioning one for a decision they make quarterly is not going to happen.

Publish the unresolved checkpoints

Pull them from the API and assemble a page:

<h1>Visual test — checkout · build 4471</h1>
<p>3 unresolved checkpoints across 4 viewports. Baseline: main@a91c03.</p>

<section>
  <h2>Checkout · payment step</h2>
  <p>Summary block shifted 24px down on viewports under 900px.</p>
  <figure><img src="…baseline.png" /><figcaption>Baseline</figcaption></figure>
  <figure><img src="…checkpoint.png" /><figcaption>This build</figcaption></figure>
  <figure><img src="…diff.png" /><figcaption>Highlighted difference</figcaption></figure>
</section>

Group by checkpoint, not by browser. With the Ultrafast Grid, one visual change produces a dozen near-identical images across browsers and viewports, and a page organised by browser makes the reviewer diff the diffs.

Restricted, not public

Checkpoint images are screenshots of a real application, which means they often contain real-looking data, internal tooling and pre-release features. Publish them to a restricted report rather than an open link — see security and password-protecting a report.

The comment is the deliverable

What you actually want back is a judgment: intended, or a bug. On a published page that judgment arrives anchored to the checkpoint — "this one's fine, the 24px is the new spacing scale; the second one is a bug" — rather than as a message referring to "the checkout one". See commenting on HTML.

Then QA accepts or rejects the baseline in the Test Manager, which remains the system of record.

Worth knowing

Publish from the CI job. After the Eyes run, fetch unresolved results and publish in the same step — see publishing from CI.
Update one report per branch, so a re-run refreshes the page instead of producing a second link with stale comments on the first.
5 MB per report body. Full-page retina checkpoints add up; link the large ones rather than inlining every frame.

Try it

Free — unlimited reports, commenters and revisions.

Publish from CI →