Quick Start

Go from zero to a live signing workflow. Describe the agreement in plain English, preview it with sample data, publish it, and run it.

You can do this entirely in Studio (web UI, no install) or in your terminal (CLI + YAML files in git). Same primitives, same engine — pick whichever fits how you already work. This guide shows both side-by-side; use the tabs.

Already know what you want? Skip ahead and fork a starter blueprint from the Library instead of describing one from scratch.

Before you start

Sign up for a SignStack account.
Open the Studio at signstack.ai.

Sign up for a SignStack account.
Install Node.js 18+ and the CLI:
```
npm install -g signstack
```
Authenticate the CLI:
```
signstack auth login
```

Step 1: Describe your agreement

You don't start from a blank editor — describe the contract in plain English and let SignStack scaffold the schemas, templates, and signing logic.

From the home screen, click New Contract and describe what you want:

"A consulting services agreement where the company signs first, then the consultant countersigns. Capture name, email, rate, and start date for the consultant."

Studio generates the primitives your contract needs. You land in the preview when it's done.

From any directory, describe the contract inline:

signstack generate "a consulting agreement where the company signs first,
then the consultant countersigns"

The CLI streams an AI-generated blueprint and its primitives into a new <blueprint-key>@<version>/ folder.

Run signstack generate without a prompt to browse the public Library and fork a starter, or pick the + New option to print setup instructions for letting your own AI assistant (Claude Code, Cursor, Codex, Gemini) drive the generation. See the AI Generation guide for the full picture.

Step 2: Preview with sample data

SignStack generates one or more scenarios (sample entity data) alongside your primitives so you can see the rendered document before anything goes out.

The preview panel is already open with a rendered PDF. Pick a different scenario from the dropdown to re-render, or hit refresh after you make edits.

Once your blueprint folder exists (from a Library fork or an AI-assistant scaffold), preview it against a scenario:

signstack preview <blueprint-key>@<version> --scenario <scenario-key>

Run it from the folder containing your YAML to open the rendered PDF locally. Re-run after edits.

If the document looks wrong, tweak the description or the generated files and preview again.

Step 3: Publish

Publishing turns your draft into an immutable version — 1.0.0, say. Once published, that exact version can never change. Every workflow you run against 1.0.0 behaves identically, forever. When you need to make updates, you edit and publish a new version (1.1.0, 2.0.0); existing workflows on older versions keep running the way you originally designed them.

Click Publish. Your draft is cut to a new version and the blueprint — plus every schema, template, asset, and function it depends on — is frozen at that version.

signstack push <blueprint-key>@<version>

The CLI publishes the blueprint and every primitive it depends on, cutting each to a new immutable version.

Step 4: Run a workflow

Once published, kick off a real signing workflow. Three ways — pick whichever fits the moment. All three produce the same workflow and send the same signing emails.

Open the blueprint, click Run, pick a scenario (or fill in the data form), and submit. The workflow starts immediately and appears in the workflow monitor.

Best for: one-off runs, testing, demos, giving non-developers a way to kick things off.

Run a workflow from the CLI against one of your scenarios:

signstack run <blueprint-key>@<version> --scenario <scenario-key>

The CLI calls the same API the Studio does.

Best for: scripted end-to-end tests, CI, running workflows from the same repo that holds your primitives.

curl -X POST https://api.signstack.ai/v1/orgs/{orgId}/namespaces/{namespaceKey}/workflows \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "blueprintKey": "consulting_services",
    "blueprintVersion": "1.0.0",
    "data": {
      "consultant": {
        "firstName": "Jane", "lastName": "Doe",
        "email": "jane@example.com", "rate": 150, "startDate": "2026-04-01"
      },
      "company": {
        "name": "Acme Corp",
        "representative": { "name": "Bob Smith", "email": "bob@acme.com" }
      }
    }
  }'

Best for: production — your application triggers workflows directly from the business event that should cause them (a deal closed, an employee hired).

See Namespaces for why namespaceKey is in every path.

The company representative gets an email to sign first; once they finish, the consultant gets theirs. Watch progress in Studio's workflow monitor or subscribe via webhooks.

Next steps

The Data-First Principle — Why SignStack starts with your data, not your documents
Blueprints and Workflows — Deep dive on the design and runtime sides
Library — Fork a pre-built contract instead of describing one from scratch
AI Generation — How to prompt SignStack for the exact contract you need

Welcome to SignStack!

The Data-First Principle