Scheduler Zero CLI

@scheduler-zero/sz is the Scheduler Zero command-line interface for browser login, owned inbox connections, organization/workspace discovery, draft creation and campaign inspection. Use it from your terminal or automation scripts with npm, Bun, pnpm or Yarn. The package declares Node.js 18+ and bundles its runtime dependencies.

Full CLI documentation · Quickstart · Command reference

Run it

npx --yes @scheduler-zero/sz@latest --help
bunx @scheduler-zero/sz@latest --help
pnpm dlx @scheduler-zero/sz@latest --help
yarn dlx @scheduler-zero/sz@latest --help

Use a Yarn version supporting dlx. Or install globally:

npm install --global @scheduler-zero/sz
sz --version
sz --help

The executables are sz and scheduler-zero. See installation and version pinning.

Sign in

bunx @scheduler-zero/sz@latest auth login

The CLI opens Scheduler Zero and prints a confirmation code. Match the code in the browser, choose an organization and selected or all current/future workspaces, choose full or read-only permissions, then click Authorize CLI. Opening the link never grants access by itself. The CLI waits by polling the server, with no localhost callback or listening port.

For SSH or manual browser opening, add --no-browser. Requests expire after ten minutes. Browser-created keys expire after 90 days and are stored in the normal per-user config directory with owner-only POSIX file permissions.

For CI, provide a personal key through your secret manager as SCHEDULER_ZERO_API_KEY instead of interactive login:

export SCHEDULER_ZERO_API_KEY='szp_your_key_here'
sz whoami --json

API keys remain limited by their restrictions and your live permissions. A saved or environment-provided key makes auth login validate that key rather than open fresh consent. See authentication and changing access.

Inspect a workspace

sz organizations list --json
sz workspaces list --json
sz campaigns list --workspace YOUR_WORKSPACE_UUID --status active --json
sz campaigns get YOUR_CAMPAIGN_UUID --workspace YOUR_WORKSPACE_UUID --json
sz campaigns create "Synthetic draft" --workspace YOUR_WORKSPACE_UUID --json
sz unibox body YOUR_MESSAGE_UUID --workspace YOUR_WORKSPACE_UUID --json

Replace the ID placeholders with UUIDs from your results. Unfiltered workspace rows include their parent organizationId and organizationName. whoami shows one representative workspace, labeled workspace since CLI 0.2.1.

unibox body reads one message's authorized body and returns contentState: empty, attachments_only, text, or media_only. Use contentState == "empty" to identify a confirmed empty email. A blank snippet alone is inconclusive. Pending or unavailable bodies return the API's retry/error response rather than an empty success. Without --json, the command prints a readable status first. The CLI negotiates content status automatically. An older API that omits contentState is reported as unknown; it is never assumed to be empty.

| Command | Purpose | | --- | --- | | auth login / login | Browser consent or save an available API key | | auth status | Check the effective credential against the API | | auth logout | Remove the saved local credential | | whoami | Show identity and a representative workspace | | organizations list | List visible parent organizations | | workspaces list | List workspaces, optionally filtered by --organization | | campaigns list | Read a page of campaigns with filters | | campaigns get <id> | Read one campaign | | campaigns create <name> | Create a draft campaign (requires campaign:create) |

Use --json for scripts and <command> --help for exact options. Campaign lists return an object with items; workspace/organization lists are arrays. Creation returns the API's campaign summary, including its ID; it does not launch or send. Quote names containing spaces. The API enforces key restrictions, live permissions, validation and Workspace isolation. Broader product actions are available through REST and MCP.

Logout clears the local file; revoke the server-side key in Settings → Personal → API keys when you want to disable access everywhere.

Guides and agent-readable docs

• Shell scripts and CI
• Options, environment variables and exit codes
• Troubleshooting
• CLI Markdown overview
• CLI llms.txt
• Complete CLI Markdown
• Machine-readable command catalog
• REST/MCP/CLI Markdown formats

Source: fundlevel-digital/scheduler-zero. License: MIT.

Connect owned inboxes

Save a private JSON file with {"reviewed":true,"logins":[{"emailAddress":"[email protected]","provider":"google_workspace","password":"REPLACE_IN_PRIVATE_FILE"}]} and set chmod 600 inboxes.json.

sz inboxes connect --workspace WORKSPACE_ID --file ./inboxes.json --sending-disabled --json
sz inboxes get BATCH_ID --workspace WORKSPACE_ID --json

The default Google flow approves the app with an authorized administrator, then connects the selected mailboxes. Use --mode connect_only, approval_only or check_admin for independent workflows. An omitted isAdmin means unknown. Optional totpSecret accepts the authenticator setup secret; temporary codes are rejected. Credentials stay out of command arguments and normal output.

All lifecycle commands use the same API as the UI and MCP: inboxes prepare, credentials, list, get, start, retry, cancel and handoff. New inboxes have warmup off; --sending-disabled also sets cold email and warmup limits to zero. See the full connection workflow.

Recovery inboxes

Connect the mailbox that receives Google sign-in codes, then select its id as recoveryInboxId in the private inbox credential file. The authorization link requires the recovery inbox owner's OAuth consent. No verification codes appear in CLI input or output.

sz recovery-inboxes connect gmail [email protected] --workspace WORKSPACE_ID --json
sz recovery-inboxes list --workspace WORKSPACE_ID --json
sz recovery-inboxes refresh RECOVERY_INBOX_ID --workspace WORKSPACE_ID --json
sz recovery-inboxes reconnect RECOVERY_INBOX_ID --workspace WORKSPACE_ID --json
sz recovery-inboxes disconnect RECOVERY_INBOX_ID --workspace WORKSPACE_ID --json

Use microsoft_outlook for Outlook/Microsoft 365 recovery mailboxes.

Thread notes

Store shared, internal Markdown plans on an Unibox conversation. These notes are never sent as email.

sz unibox notes list <thread-id> --workspace <workspace-id> --json
sz unibox notes get <thread-id> <note-id> --workspace <workspace-id> --json
sz unibox notes create <thread-id> --workspace <workspace-id> --file note.json
sz unibox notes update <thread-id> <note-id> --workspace <workspace-id> --file changes.json
sz unibox notes delete <thread-id> <note-id> --workspace <workspace-id>

note.json contains {"title":"Plan","content":"# Next steps\n- Follow up"}. Updates accept either field and preserve the other. Use --file - to read JSON from stdin. Creation accepts an optional UUID id; the CLI generates one for each new note when omitted, keeping API retries safe. Reuse an explicit id when retrying across CLI processes.

List returns metadata without Markdown bodies, up to 50 notes by default. Use --limit 1..100 and pass the returned nextCursor to --cursor for another page. Use get for full content. IDs are local UUIDs from the thread list, not provider thread IDs. Reads require unibox:read; creation, updates and deletion require unibox:label in the conversation's owning workspace. Notes are visible to everyone who can read the conversation.