Quickstart
Create a workspace, get your keys, and make your first authenticated call.
Quickstart
This page is the shortest path from signing up to reading your own workspace data from code. It describes the flow that exists today; the administration pages linked at the end cover the decisions behind each step.
A workspace administrator owns key issuance. If someone else administers your workspace, ask them to complete steps 1 and 2 and send you only the keys your surface needs.
The product listing example below requires the Ecommerce feature. Select Ecommerce during onboarding before you create the workspace. If you choose a custom feature set, use a first-call example supported by one of the features you enabled; Feature Planning lists the available choices.
Create a workspace
Sign up at 01.software and complete onboarding. The wizard asks what you are building and preselects a matching feature set — you can change any of it before creating the workspace.
Feature choice is not permanent. Feature Planning explains what each feature adds and which plan it needs.
Copy your keys
The last onboarding screen shows your Secret Key once. Copy it then, or use Download .env to save both keys as environment variables:
NEXT_PUBLIC_SOFTWARE_PUBLISHABLE_KEY=pk01_...
SOFTWARE_PUBLISHABLE_KEY=pk01_...
SOFTWARE_SECRET_KEY=sk01_...The download is named .env.01software. Rename it to whatever your project
reads — .env.local for a Next.js app.
| Key | Prefix | Where it belongs |
|---|---|---|
| Publishable Key | pk01_ | browser code; safe to ship to the client |
| Secret Key | sk01_ | server code only; never send it to a browser |
If you miss the secret key, issue a new one from API Keys in Console — the original is stored hashed and cannot be shown again. The publishable key stays visible on your workspace record.
A secret key performs privileged work on your workspace. Keep it in server environment variables, never in client bundles or committed files.
Start a project
First choose the implemented support level in Build Options. For a new opinionated Next.js app, run:
npm create 01-software-app@latestFor an existing app, add the SDK wiring in place:
npx @01.software/initBrowser authorization is the recommended greenfield choice. create-01-software-app first writes a secret-free scaffold and completes dependency installation, then asks a verified workspace administrator to authorize one purpose-specific development app. Only after that flow succeeds does it exclusively create .env.local with the workspace's existing pk01_ and a new development sk01_; it never copies the Human CLI's pat01_ into the app.
If you use --no-install, the command creates no credential and prints both the install command and an exact --connect command. Run those commands in order. --connect accepts only the matching installed, secret-free scaffold and preserves any existing or ambiguous .env.local for manual recovery.
Existing-project @01.software/init remains a separate prompt-driven flow and does not share the greenfield development-app operation. Targets that use an env file default to .env.local for Next.js and .env for the other generated-file targets; vanilla browser JavaScript uses an inline placeholder and Edge wiring accepts runtime bindings instead. Init does not open browser authorization or call /api/cli/exchange.
In @01.software/init targets that use credential prompts, SDK authentication is separate from optional AI-tool setup. Leaving AI tools unselected still offers Enter manually or credential-free Skip for now. Manual entry accepts only a canonical pk01_ and, for a server-capable target, a canonical development sk01_. Vanilla browser JavaScript instead writes an inline placeholder and does not prompt for keys.
Before installation, scaffold, environment, or AI-context writes, existing-project init validates manual input and every non-empty app credential in the selected existing env file. It rejects pat01_, malformed values, duplicate declarations, and a partial server credential pair while preserving the existing file unchanged.
create-01-software-app also accepts --auth manual with an existing canonical pk01_ plus development sk01_, or --auth skip to scaffold against demo data with no workspace connected. It rejects pat01_ as an application key. @01.software/init is prompt-driven and takes no flags.
Make your first call
This app/page.tsx example is a Next.js Server Component. It runs on the server without a browser Origin, so browser CORS registration is not required for this server execution.
If you move this call into a Client Component or other browser code, first register its origin under Integrations & Keys. Browser requests from an unregistered origin are refused.
import { createClient } from '@01.software/sdk'
const client = createClient({
publishableKey: process.env.NEXT_PUBLIC_SOFTWARE_PUBLISHABLE_KEY!,
})
const { cards } = await client.commerce.product.listingPage({
limit: 10,
})Server code adds the secret key for privileged work:
import { createServerClient } from '@01.software/sdk/server'
const client = createServerClient({
publishableKey: process.env.NEXT_PUBLIC_SOFTWARE_PUBLISHABLE_KEY!,
secretKey: process.env.SOFTWARE_SECRET_KEY!,
})Next Actions
Deploy
Move your keys to the deploy environment and allow the deployed origin.
SDK Guide
Import paths, client boundaries, and the full operation surface.
Authentication
What each credential type may do and how requests are authorized.
Integrations & Keys
Browser origins, webhooks, analytics, and credential ownership.
Feature Planning
Choose the smallest feature set that fits your launch goal.