The SDKs
The Stardeck packages installed in every app, what each one owns, and where to read its full API.
Every platform capability is an npm package under the
@stardeck-customer-apps/* scope. They are published publicly, so a clone plus
npm install needs no registry token.
Each SDK ships its own complete API reference inside the installed package, as
a SKILL.md file. That file is the reference — it is versioned with the code, so
it cannot drift from the API you actually have installed.
# From apps/web
cat node_modules/@stardeck-customer-apps/payments-sdk/SKILL.md
# If your install is hoisted
find . -path '*/@stardeck-customer-apps/*/SKILL.md' -not -path '*/.git/*'Your coding agent reads these files from your checkout. With it connected to Stardeck, it can also load the platform's own skills, such as the design skills, over MCP.
Installed in every app
| Package | What it owns |
|---|---|
project-auth | Sign-in, sessions, RBAC, SSO, admin and user dashboards, test personas |
data-store-sdk | Request-time database and file access against your organization's Data Stores |
payments-sdk | Checkout, subscriptions and billing through the platform's payment providers |
email-sdk | Transactional email |
integrations-sdk | Messaging channels (LINE, Slack), Google Sheets sync, and Platform Identity |
scheduling-sdk | Scheduled and recurring jobs |
document-sdk | HTML to PDF generation |
starlens | Structured extraction from photos, PDFs, audio and video, with per-field issues |
edge-sdk | On-premise hardware — receipt printers, cash drawers, customer displays |
cross-app | Calling API endpoints on sibling apps in the same organization |
storage-sdk | File storage. Legacy — prefer a storage-type Data Store for new work |
client-utils | Helpers for running inside the Stardeck shell, including page context |
testing | The hermetic test harness: in-process Postgres and simulated platform services |
Development-only packages
| Package | What it owns |
|---|---|
@stardeck-customer-apps/compose | Regenerates the Module wiring files (the *.gen.ts registries and route stubs) from each Module's module.json. It has its own SKILL.md |
@stardeck-customer-apps/eslint-plugin | The lint rules that enforce platform constraints — Kysely transactions, Module imports, generated-file markers, className interpolation |
@stardeck-customer-apps/tsconfig | Shared TypeScript configuration |
Not for app code
@stardeck-customer-apps/kernel is the internal primitive layer the other SDKs
build on — HMAC request signing and retry behavior. App code must not import it.
If you are reaching for it, the capability you want belongs to one of the SDKs
above.
How to choose
flowchart TB
Q{"What do you need?"}
Q -->|"Store or read data"| A["data-store-sdk"]
Q -->|"Know who the user is"| B["project-auth"]
Q -->|"Take money"| C["payments-sdk"]
Q -->|"Send a message out"| D["email-sdk · integrations-sdk"]
Q -->|"Run something later"| E["scheduling-sdk"]
Q -->|"Produce a document"| F["document-sdk"]
Q -->|"Read a document or photo"| S["starlens"]
Q -->|"Touch hardware"| G["edge-sdk"]
Q -->|"Ask another app"| H["cross-app"]What keeps an app upgradeable:
- Use the SDK rather than the wire. Every SDK signs its own platform calls. Hand-built requests to platform endpoints are the code most likely to break on a platform upgrade.
- Do not rebuild what an SDK owns. A bespoke auth table, an email queue, or a file-upload service is work the upgrade rail cannot maintain for you.