Kelviq CLI

The Kelviq CLI is in beta. It’s fully functional — and safe by design, with previews and confirmations before every write — but commands, flags, and the --json output shape may still change between releases. Pin an exact version in CI and review the release notes before upgrading.

The Kelviq CLI (@kelviq/cli) lets you manage your pricing catalog as code instead of dashboard clicks. Your products, features, plans, entitlements, and prices live in a single typed TypeScript file — kelviq.config.ts — that you can review, diff, and version-control like the rest of your codebase.

import { product, feature, plan } from '@kelviq/cli/config';

export const app = product({
  identifier: 'my-app',
  name: 'My App',
  taxCode: 'saas',
});

export const seats = feature({
  identifier: 'seats',
  name: 'Seats',
  type: 'CUSTOMIZABLE',
});

export const pro = plan({
  identifier: 'pro',
  name: 'Pro',
  product: 'my-app',
  entitlements: [{ feature: 'seats', value: 5 }],
});

The loop is complete in both directions: kelviq pull turns a live environment into a config file, and kelviq push deploys a config file back — with a diff preview, draft-first writes, and explicit gates before anything customer-facing changes. kelviq promote moves your whole sandbox catalog to production the same way.

Why pricing-as-code?

Your pricing model decides what customers are billed, what features they can reach, and what limits they hit. It is production infrastructure. But when it lives only in a dashboard, it’s managed unlike any other production infrastructure you run:

Changes are invisible to your engineering workflow. A plan edit doesn’t show up in a pull request, doesn’t get a review, and doesn’t appear in git log. The first your team hears of it may be a support ticket.
There’s no meaningful diff. “What exactly changed in our Pro plan last quarter?” has no good answer when the only record is the current dashboard state.
Environments drift silently. Sandbox and production start identical and slowly diverge — a limit tweaked in one, a price fixed in the other — until “it worked in sandbox” stops meaning anything.
The model lives in people’s heads. Understanding your own packaging means clicking through screens, plan by plan, feature by feature.

A kelviq.config.ts under version control changes each of those:

Without	With pricing-as-code
Dashboard edits leave no trail	Every change is a commit — author, date, diff, and the PR discussion that approved it
Pricing changes skip review	Pricing changes go through the same pull-request review as any other production change
Sandbox/production drift is invisible	Pull both environments and `diff` them — drift is a one-command check
The catalog is spread across dashboard screens	The whole monetization model is one readable file — onboarding is “read this”
Mistakes surface at runtime, via the API	The file is typed: a misspelled field or invalid enum is a compile-time error with a “did you mean” suggestion, before Kelviq ever sees it

The concepts in the file map one-to-one to Kelviq’s own — products, features, plans, entitlements, prices. If you know the core concepts, you already know the format.

What you can do today

Put your catalog under version control

If you’ve already built your pricing in the dashboard, one command gets it into git:

kelviq pull
git add kelviq.config.ts && git commit -m "Snapshot pricing catalog"

From here on, re-running kelviq pull --force and committing captures every catalog change as a diff. Run it on a schedule in CI and dashboard edits stop being invisible — they become commits your team can read.

Catch drift between sandbox and production

Pull both environments and compare:

kelviq pull -o sandbox.config.ts --force
kelviq pull --prod -o production.config.ts --force
diff sandbox.config.ts production.config.ts

Because the config format references everything by stable identifier slugs — never per-environment UUIDs — the two files are directly comparable. A clean diff means your environments genuinely match; anything else shows you exactly where they don’t. Run it before a launch, after a migration, or whenever “it worked in sandbox” needs verifying.

Review pricing changes like code — then deploy them

Propose a pricing change by editing kelviq.config.ts in a pull request — the reviewer sees exactly what changes: the new limit, the removed entitlement, the price that swapped. After the merge, deploying is one command with a preview built in:

kelviq push --dry-run   # exactly what would change, zero writes
kelviq push             # apply as drafts, after showing the diff and asking
kelviq push --publish   # and publish the changed plans, after a second confirmation

Everything push writes is a draft by default — nothing a customer sees changes until you publish, and migrating existing customers to new entitlements or pricing always requires its own explicit flags. Pricing changes get the full GitOps treatment: PR → review → merge → push, with the dashboard as a viewer rather than the editor.

Promote sandbox to production

Build and test your pricing in sandbox, then move it to production in one reviewed step:

kelviq promote --dry-run   # read-only: exactly what production would change
kelviq promote             # apply it, drafts first, confirmation required

Promote matches resources across environments by identifier — no files, no UUID bookkeeping — and inherits every one of push’s safety rails.

Give your AI tools your pricing model

A typed, self-contained TypeScript file is something coding assistants are genuinely good at working with — ask one to “add a Team plan between Pro and Enterprise with 25 seats” and the builders’ types keep it honest; anything invalid fails to compile. Pair the CLI with the Kelviq MCP server and your assistant can read the config for context and apply catalog changes through the API today.

Start a new project from a template

kelviq init

Writes a starter kelviq.config.ts to edit by hand — useful when you’re designing pricing for a new product and want to sketch the model in code (with autocomplete and validation) before anything exists in Kelviq.

How it fits with the rest of Kelviq

Each Kelviq surface has a distinct job — the CLI doesn’t replace the others:

Tool	Use it for
CLI (this)	Managing the catalog itself — the definition of your products, features, plans, and prices — as versioned code.
Dashboard	Visual management, analytics, customer operations, feature renames — and reviewing the drafts push creates.
Backend & frontend SDKs	Your application’s runtime integration — checkouts, entitlement checks, usage reporting inside your product.
MCP server	Driving the Kelviq API conversationally from Claude, Cursor, or any MCP client.
REST API	Everything, programmatically — the layer all of the above are built on.

A useful rule of thumb: SDKs are how your product talks to Kelviq at runtime; the CLI is how your team manages what Kelviq is configured to sell.

Installation

Requires Node.js 18 or newer.

npm install -g @kelviq/cli

Verify the install:

kelviq --version

Quickstart

Step 1: Authenticate

kelviq login

login opens the dashboard’s API keys page in your browser and prompts you to paste a Server API Key. Input is masked and the key is stored locally with owner-only file permissions. The CLI targets your sandbox environment by default. To store a production key too, run kelviq login --prod. See Environments & authentication for how keys are stored and how to use environment variables instead (for example, in CI).

Step 2: Pull your catalog

kelviq pull

pull fetches your sandbox catalog — products, features, plans, entitlements, and prices — and writes it as a kelviq.config.ts in the current directory. If you’ve already set up pricing in the dashboard, this is the fastest way to get it under version control.

Step 3: Or start from scratch

kelviq init

init writes a starter kelviq.config.ts you can edit by hand. The file is plain TypeScript with full autocomplete — misspell a field and the compiler tells you before Kelviq ever sees it.

Step 4: Check where you’re pointed

kelviq env

Prints which environment the CLI targets and which keys are configured — useful before any command that touches your account.

Step 5: Make a change and deploy it

Edit the config — bump a limit, add a plan — then:

kelviq push --dry-run   # see exactly what would change
kelviq push             # apply it as drafts, after confirmation

When you’re happy, kelviq push --publish makes the changed plans live, and kelviq promote carries the whole catalog from sandbox to production.

The commands

Command	What it does
`kelviq init`	Write a starter `kelviq.config.ts`.
`kelviq login`	Paste and store a Server API key.
`kelviq logout`	Remove stored API keys.
`kelviq env`	Show the configured environment and key status.
`kelviq pull`	Write your remote catalog to `kelviq.config.ts`.
`kelviq push`	Deploy a `kelviq.config.ts`: diff, confirm, draft-first writes, optional publish and prune.
`kelviq promote`	Move the sandbox catalog to production with the same preview and gates.

See the full command reference for every flag, and the kelviq.config.ts reference for the file format.

What’s coming

Catalog browse commands — list and inspect products, features, and plans without a full pull.
Browser-based login — a pairing flow that mints a scoped key from your dashboard session, replacing paste-a-key.

Backend Integration

Frontend Integration

Promotions UI

CLI

Why pricing-as-code?

What you can do today

Put your catalog under version control

Catch drift between sandbox and production

Review pricing changes like code — then deploy them

Promote sandbox to production

Give your AI tools your pricing model

Start a new project from a template

How it fits with the rest of Kelviq

Installation

Quickstart

Step 1: Authenticate

Step 2: Pull your catalog

Step 3: Or start from scratch

Step 4: Check where you’re pointed

Step 5: Make a change and deploy it

The commands

What’s coming

​Why pricing-as-code?

​What you can do today

​Put your catalog under version control

​Catch drift between sandbox and production

​Review pricing changes like code — then deploy them

​Promote sandbox to production

​Give your AI tools your pricing model

​Start a new project from a template

​How it fits with the rest of Kelviq

​Installation

​Quickstart

​Step 1: Authenticate

​Step 2: Pull your catalog

​Step 3: Or start from scratch

​Step 4: Check where you’re pointed

​Step 5: Make a change and deploy it

​The commands

​What’s coming

Why pricing-as-code?

What you can do today

Put your catalog under version control

Catch drift between sandbox and production

Review pricing changes like code — then deploy them

Promote sandbox to production

Give your AI tools your pricing model

Start a new project from a template

How it fits with the rest of Kelviq

Installation

Quickstart

Step 1: Authenticate

Step 2: Pull your catalog

Step 3: Or start from scratch

Step 4: Check where you’re pointed

Step 5: Make a change and deploy it

The commands

What’s coming