Skip to content

How the SDK is generated ​

Nothing in the SDK's API surface is written by hand. The gateway documents every route, socket frame and error code in Go next to its handler, and its build refuses anything undocumented (go run ./services/api/cmd/openapi -check). The SDK is generated from those documents.

text
Go handlers + docs_*.go
   │  go run ./services/api/cmd/openapi            (also served at /openapi.json, /asyncapi.json)
   ▼
spec/openapi.json + spec/asyncapi.json
   │  scripts/generate.mjs
   ├─► src/gen/schema.ts      every request and answer type (openapi-typescript)
   ├─► src/gen/resources.ts   staff.* / trader.* methods with their docs
   ├─► src/gen/ws.ts          typed socket frames
   └─► docs/crm/reference/**  the reference pages of this site

Commands ​

bash
cd sdk/js
npm install
npm run build                                 # spec → generate → compile
NOVIQA_API_URL=https://dev.example.com npm run spec   # take the spec from a running gateway instead
npm test                                      # SDK tests + type-check every cookbook recipe
npm run docs                                  # this site, built into docs/crm/.vitepress/dist
npm --prefix ../../docs/crm run dev           # this site with live reload

When the API changes ​

  1. Change the handler and its docs_<area>.go entry (see the gateway's developer guide).
  2. npm run build in sdk/js. New methods and types appear; removed ones disappear.
  3. npm test. A recipe that no longer matches the API fails to compile, so the cookbook never goes stale.

Method names come from the path (list, retrieve, create, update, delete, plus the action, e.g. approve). The few names the pattern cannot guess are in the RENAMES table of scripts/generate.mjs.