Skip to content
Vizzly Docs

SDK Overview

Vizzly keeps the capture side intentionally small.

Most integrations boil down to one idea: your tests send screenshots through a Vizzly client, and the CLI handles the rest.

If you are setting up Vizzly for the first time, start with Quick Start. It walks through the whole path: create a project, create a token, capture one screenshot, and review the first baseline.

The main paths

JavaScript client

For most JavaScript and Node test runners, use the built-in client from @vizzly-testing/cli.

Terminal window
npm install -D @vizzly-testing/cli
import { vizzlyScreenshot } from '@vizzly-testing/cli/client';

Framework-specific packages

Vizzly also has integrations for workflows like:

  • Storybook
  • static sites
  • Vitest
  • Ember
  • Ruby
  • Swift

Each one is documented in this SDK section.

Local mode vs cloud mode

Local development

Terminal window
vizzly tdd start

Your tests post screenshots to the local server. Comparisons stay local in .vizzly/.

CI and team review

Terminal window
vizzly run "npm test" --wait

The same client-side capture flow works. vizzly run wraps the test command, starts the capture server, and uploads the resulting build for shared review.

When a capture is uploaded

In cloud mode, the local server queues screenshots for upload. A successful capture response means the local server accepted it; the cloud upload can still fail afterward. Check the CLI’s final summary for uploaded, reused, and failed screenshots.

vizzly run reports upload failures without failing passing tests. See upload failures for the build status and exit-code behavior. All cloud captures follow the same image and name requirements.

What to use by default

If you are in JavaScript, start with @vizzly-testing/cli/client.

If you need a custom integration in another language, use Build Your Own Vizzly SDK and mirror the local HTTP contract.

Next steps