SnozeDevelopers
API referenceWorkspaces

Seed a workspace from an approved AI draft plan

Seeds the workspace from the draft plan the user reviewed, and possibly edited, in the describe-your-work onboarding flow, re-normalizing the plan on the server before anything is created. Needs the same `databases:write` and `surfaces:write` permissions as applying a fixed starter. A plan that normalizes to nothing left to build is rejected as a validation error.

POST
/v1/workspaces/{workspaceId}/starter-draft

Authorization

apiKey
headerAuthorizationBearer <snoze_sk_…>

Workspace API key created in Workspace settings → API keys. Scopes on the key bound what it can read and write.

Path Parameters

workspaceId*string

Request Body

application/json
  1. body
operationId?|null
plan*

Response Body

Success

application/json
  1. response
data*
Example Request
curl -X POST 'https://api.snoze.dev/v1/workspaces/string/starter-draft' \  -H 'Content-Type: application/json' \  -d '{  "plan": {    "headline": "string",    "nodes": [      {        "type": "database",        "ref": "string",        "label": "string",        "fields": [          {            "key": "string",            "label": "string",            "kind": "text"          }        ],        "records": [          {            "title": "string"          }        ]      }    ]  }}'
Example Response
{  "data": {    "itemIds": [      "string"    ],    "folderItemIds": [      "string"    ],    "headline": "string",    "databaseCount": 0,    "pageCount": 0  }}

Seed a workspace from a starter template

Seeds the workspace with the databases, records, views, and pages of the named onboarding starter template, and records the onboarding analytics events around it. The seeding runs as the caller, so it requires `databases:write` and `surfaces:write` in the workspace. It is not idempotent: applying a starter twice creates the content twice.

Mint a short-lived realtime connection ticket

Issues a single-use ticket, valid for 30 seconds, that the browser exchanges for a realtime connection to this workspace. Requires a Clerk session with a synced profile plus `workspace:read`; API keys cannot acquire a realtime identity. Deliberately not idempotent, because replaying the response would hand back a ticket the gateway has already consumed, and it returns an upstream error when the ticket store is unavailable.