Sign in
Pricing
How it worksThe docs visuals workflow from CI capture to permanent URLs.Visual DiffReview changed docs visuals before they publish.CI/CD CaptureCapture docs visuals in the pipeline you already run.CDN URLsPermanent URLs that stay current when you ship.IntegrationsCI runners and docs platforms that fit the same workflow.
BlogWriting on docs visuals, CI/CD capture, and visual debt.Visual DebtUnderstand the cost of stale docs visuals.AboutWhy we built Reshot and how we think about the problem.Docs-as-Code GuidePractical guidance for versioned docs workflows.
Sign in
BlogProduct Updates

Certified Targets: the Reshot release that turns reliability into a public contract

We are narrowing the promise on purpose. This release makes Reshot production-stable for a named set of certified apps, with an explicit target contract and release gate behind it.

Reshot Team
April 2, 20266 min read

This release changes the promise. Instead of implying the same maturity across every possible app, Reshot now ships with a Certified Targets model: a small named set of targets that pass an explicit integration contract and a full end-to-end release gate.

That matters because most screenshot automation failures are not random chaos. They are contract drift. A selector changes. A route stops being stable. A publish succeeds but hosted delivery breaks. Authentication works locally but not in the release path. Certified Targets is our answer to that class of failure.

What ships in this release

  • A new target contract in reshot.config.json
  • Three new CLI commands: reshot doctor target, reshot verify publish, and reshot certify
  • Deterministic readiness audits for certified scenarios
  • Structured diagnostics for publish, pull, delivery, browser errors, and route mismatches
  • Hosted delivery verification as part of certification, not a separate afterthought

Certified in this release

  • ClaraDB docs workflows
  • PaperJSX platform flows
  • Reshot reference platform and hosted delivery flows

Why we made the promise narrower

A broad reliability claim is easy to market and hard to trust. A narrower claim with named targets, explicit rules, and a machine-readable report is much more useful. Teams evaluating Reshot can now see what “production-stable” means in practice, and teams onboarding a new app can follow the same contract to become candidates and then certified targets.

The operational change behind the marketing

The release is backed by a real gate:

  1. Route audit
  2. Readiness audit
  3. Capture
  4. Publish
  5. Pull or export verification
  6. Hosted delivery verification
  7. Live-auth smoke when the target requires it

If a certified target fails one of those stages, the certification report fails.

What this means for new targets

New targets do not need a chaos lab. They need deterministic readiness, stable selectors, a declared auth mode, and a publish path that resolves through the canonical hosted delivery contract. That is why this release also includes the candidate path: a target can integrate progressively instead of pretending to be production-ready on day one.

The best place to start is the Certified Targets guide.

Start with one docs visual workflow.

Run one real docs capture on the free tier and see whether the maintenance disappears.

Start capturing free