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

  1. Sign up for a SignStack account.
  2. Open the Studio at signstack.ai.
  1. Sign up for a SignStack account.
  2. Install Node.js 18+ and the CLI:
    npm install -g signstack
    
  3. 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 writes YAML files for each primitive the contract needs into a new project folder — blueprint, schemas, assets, templates, and custom functions if any.

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.

signstack generate prints the exact preview command for the blueprint it built. It'll look like this:

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

Run it 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. signstack generate prints the exact push command.

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.

signstack generate also prints the exact run command, using one of the generated 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 <TOKEN>" \
  -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