SalesShift setup guide
Billing, API keys and workspace sync
Use this page when a new workspace must go from zero to a verified SalesShift client. The sequence is intentional: choose a plan, create a developer key, bind the workspace to its node, sync the node credentials, and only then run a CLI, SDK or AI smoke test.
A browser session and a developer key represent the same workspace. The key is exchanged for a short-lived JWT by the control plane; the JWT is what the REST API and SDKs use for protected calls. Never paste a provider secret into source code or commit ~/.vxcloud/credentials.json.
The connection model
| Layer | What it owns | How you verify it |
|---|---|---|
| Workspace | Organization, members, plan, connected mailboxes and node binding. | GET /billing/subscription |
| Control plane | Authentication, billing, API-key exchange, entitlements and node discovery. | GET /auth/nodes/ |
| Tenant node | Self-hosted crawling, sending and agent work when the workspace is self-hosted. | GET /billing/self-hosted |
| Client | vxcli, Python/TypeScript/Go SDKs, or direct HTTP with the same auth envelope. | vxcli auth whoami |
Step-by-step billing setup
Billing changes are workspace-level. The safe order is read, choose, checkout, confirm, then re-read. A plan change does not silently create a mailbox, send an email or enroll a contact.
- 1
Read the catalogue and current state
In the UI open
Billing. For automation, read both the plan catalogue and the current subscription before choosing a plan.export API=https://api.vxcloud.io/api/v1/salesshift curl -s "$API/billing/plans" -H "Authorization: Bearer $SS_TOKEN" curl -s "$API/billing/subscription" -H "Authorization: Bearer $SS_TOKEN" curl -s "$API/billing/entitlements" -H "Authorization: Bearer $SS_TOKEN"vxcli salesshift billing plans vxcli salesshift billing subscription vxcli salesshift billing entitlements - 2
Start checkout or activate a free plan
Paid plans use hosted checkout. A free plan uses
activate. Do not callactivatewith a paid plan code and do not treat a successful checkout-session creation as a paid subscription yet.curl -s -X POST "$API/billing/checkout" \ -H "Authorization: Bearer $SS_TOKEN" \ -H 'Content-Type: application/json' \ -d '{"plan_code":"starter","seats":1}' # Open the returned checkout_url, complete payment, then continue to step 3.vxcli salesshift billing activate # The server refuses a downgrade when an active paid or granted plan exists. - 3
Confirm and inspect the subscription
After the hosted payment returns, confirm the checkout with its idempotency reference, then read the subscription and event log. The event log is the audit trail when a browser still displays an old status.
curl -s -X POST "$API/billing/checkout/confirm" \ -H "Authorization: Bearer $SS_TOKEN" \ -H 'Content-Type: application/json' \ -d '{"checkout_id":"chk_…"}' vxcli salesshift billing subscription vxcli salesshift billing events vxcli salesshift billing invoices - 4
Use the customer portal for renewal or cancellation
The portal is the supported place to update cards, download receipts, cancel at period end, or resume a pending cancellation. Re-read
subscriptionafter returning from the portal.vxcli salesshift billing portal vxcli salesshift billing cancel --at-period-end vxcli salesshift billing resume
Create and rotate a developer API key
In the dashboard open Developer → API keys, create a key with a descriptive name and copy it once. For CI, use a separate key per environment and rotate it by creating the replacement before revoking the old one. The raw value is never returned again after creation.
/api/v1/auth/developer/keysCreate a workspace-scoped keyvxcli auth login --username <workspace-user> --api-key xc_live_…
vxcli auth whoami
# Direct exchange used by clients
curl -s -X POST https://api.vxcloud.io/api/v1/auth/developer/keys/login \
-H 'Content-Type: application/json' \
-d '{"username":"<workspace-user>","api_key":"xc_live_…"}'- Keep
xc_live_*keys in a secret manager or CI secret store. - Use
xc_test_*for sandbox calls where your tenant supports them. - Do not use AWS, GitHub, Anthropic or OpenAI keys as a VxCloud login key.
- After rotation, run
vxcli auth login --forceand thenvxcli auth validate.
Bind and sync the workspace node
A self-hosted workspace uses a tenant node for crawling, sending and agent execution. The register operation is a handshake: the control plane calls the node over HTTPS and checks that the node reports the same workspace identity. A hostname that resolves but reports a different tenant must be refused.
- 1
List the nodes visible to the workspace
vxcli node list vxcli node current vxcli node refresh - 2
Register the HTTPS node for SalesShift
vxcli salesshift billing node register https://node1.vxcloud.io vxcli salesshift billing node # REST equivalent curl -s -X POST "$API/billing/self-hosted/node" \ -H "Authorization: Bearer $SS_TOKEN" \ -H 'Content-Type: application/json' \ -d '{"host":"https://node1.vxcloud.io"}' - 3
Sync workspace credentials to the node
Use
Sync With Workspacefrom the node card in VxCloud, or the node sync action in your deployment tooling. The sync writes the node identity, workspace API key reference and configured AI provider references; it does not expose raw provider secrets to the browser.curl -s https://node1.vxcloud.io/api/v2/health curl -s https://node1.vxcloud.io/api/v2/version vxcli status - 4
Detach safely when moving a workspace
Detach only after the replacement node is ready. Detaching stops self-hosted sending, crawling and agent work until another node is registered.
vxcli salesshift billing node detach --yes
CLI and SDK feature coverage
The clients share the same API contract. Use the CLI for interactive operations and CI, the SDKs for application code, and REST for any newly released endpoint before the next client release lands.
| Surface | Current coverage | Use it for |
|---|---|---|
vxcli salesshift | Analytics, billing, calendar, campaigns, contacts, companies, contracts, deals, deliverability, email, invoices, leads, lists, opportunities, quotes, reports, sequences, SEO, tasks, social and webmaster. | Shell scripts, CI and repeatable operations. |
Python / TypeScript / Go | Auth, sessions, deploy, cloud, workspace, agent control, chat, observability, billing, node registration and the SalesShift email/leads surface; see each SDK page for method-level parity. | Backend services and typed integrations. |
C++ / Java | The published SalesShift client surface is intentionally narrower (email and leads); use REST for billing, sequences, campaigns and CRM operations until those SDKs catch up. | Existing JVM/native integrations. |
REST | The source of truth for every route, including new platform-billing and messaging operations. | Early access, webhooks and unsupported SDK methods. |
A safe client preflight
vxcli auth status
vxcli auth whoami
vxcli node current
vxcli salesshift billing entitlements
vxcli salesshift contacts list --limit 1 --output json
# SDKs load the same credentials written by vxcli
python - <<'PY'
import vxsdk
c = vxsdk.Client.load_from_vxcli()
print(c.salesshift.billing_entitlements())
print(c.salesshift.contacts.list(limit=1))
PYAI providers and Sales Agent safety
AI drafting is configured per workspace. Store provider credentials in the workspace settings or Vault, select the provider/model in the UI, and run a read-only prompt before enabling any send-capable action. Claude, OpenAI and Ollama are supported provider paths; the exact model catalogue is workspace-dependent.
@sales Read-only preflight: count saved contacts in the USA and return the top three
company names. Do not draft, send, enroll, or modify anything.- Read-only: list, count, inspect and report. No approval is needed.
- Draft-only: return recipient, subject and body labelled
review only, not sent. - Send-capable: create a pending draft and wait for explicit approval.
- After a send, verify the tracking row and contact audit; do not trust a UI toast alone.
Verification and troubleshooting
| Symptom | Check first | Expected result |
|---|---|---|
| 401 / invalid API key | vxcli auth login --force | Auth exchange returns a JWT and whoami resolves the workspace. |
| 402 / payment required | billing entitlements | The capability and remaining allowance explain the refusal. |
| Node offline or stale version | /api/v2/health and /api/v2/version | Health is 200 and running_version/digest match the desired image. |
| AI provider unavailable | Workspace AI settings + node sync | Provider is configured, key reference is present and a read-only prompt succeeds. |
| UI and CLI disagree | auth whoami plus node current | Both clients point at the same organization, workspace and node. |
For the complete route list see the REST API reference, then use the vxcli reference or the SDK reference for the client equivalent.