All five primitive resources — Blueprints, Templates, Schemas, Assets, and Functions — share the same lifecycle and the same CRUD shape. Learn the pattern once; apply it to every kind.

In practice, most teams don't call these endpoints directly. Resource management happens through Studio (visual editor), the signstack CLI (YAML in git → push to deploy), or the embeddable <ss-resource-editor> component (white-label authoring inside your own product). The raw endpoints below are what those three surfaces call under the hood — call them directly when you're building CI/CD pipelines, automated provisioning, or programmatic management flows.

Identity

Every resource has:

• A caller-supplied key (string, unique within the namespace + kind)
• A version — semantic (<major>.<minor>.<patch>); published versions are immutable. Resources may also carry a single editable draft version — convenient for iterating before publishing the next semver, but not required: you can also POST directly at a specific semver and skip the draft entirely.

The canonical form for referencing a specific version is <key>@<version> (e.g., offer_letter@1.2.0, nda@draft).

Standard endpoints

Each kind exposes the same eight verbs, with <kind> ∈ blueprints | templates | schemas | assets | jsonata-functions:

Endpoint	Purpose
POST .../<kind>	Create a new resource — as a draft or directly at a semver
GET .../<kind>	List all resources of this kind
GET .../<kind>/{key}	Read by key — returns the latest version, or pass ?version=<v> to read a specific version (draft, 1.2.0, etc.)
PUT .../<kind>/{key}/versions/draft	Update the draft
POST .../<kind>/{key}/versions/draft/publish	Publish the draft as a new immutable semver
GET .../<kind>/{key}/versions	List all versions for this key
DELETE .../<kind>/{key}/versions/{version}	Delete a draft (published versions cannot be deleted)

All paths are relative to /v1/orgs/{orgId}/namespaces/{namespaceKey}/.

Mutating endpoints honor the standard HTTP ETag / If-Match round-trip for optimistic locking.

Publishing (POST /versions/draft/publish)

If you've been iterating in a draft, publishing converts it into a frozen semver release. The request body specifies which segment to bump:

{ "versionType": "patch" }   // 1.2.0 → 1.2.1
{ "versionType": "minor" }   // 1.2.0 → 1.3.0
{ "versionType": "major" }   // 1.2.0 → 2.0.0

After publishing, the draft becomes the new published version — there's no separate draft anymore. To keep iterating, POST a new draft (typically copying from the just-published version). If you create a resource directly at a semver without ever using a draft, this endpoint isn't needed for that resource.

Per-kind specifics

The resources below have extra endpoints beyond the shared CRUD:

• Blueprints — POST .../blueprints/render (preview a blueprint without launching a workflow)
• Templates — POST .../templates/render (render a template against entity data)

What about Scenarios?

Scenarios sit outside this lifecycle. They're test fixtures — named bundles of entity data used to preview blueprints and templates with realistic inputs. They have no version, no draft/published states, no publish operation, and no immutability constraint; every scenario is a single mutable record keyed by key.

If you're looking for that surface, see Scenarios.