Client SDKs

There are TypeScript and Python client SDKs, installable via npm / pip. They’re auto-generated from api/openapi.yaml on every PR, so they always track the real server. For any other language, generate your own client from the same spec:

https://crsdk.github.io/alpha-sdk-api/api-reference/openapi.yaml

Published clients

The TypeScript and Python clients are generated from the spec with Fern and published — install them like any package:

TypeScript
Python

npm install @alpha-sdk/client

import { AlphaSDKClient } from "@alpha-sdk/client";

const client = new AlphaSDKClient({ environment: "http://localhost:8080" });
const { cameras } = await client.cameras.list();

pip install alpha-sdk-client

from alpha_sdk_client import AlphaSDKClient

client = AlphaSDKClient(base_url="http://localhost:8080")
cameras = client.cameras.list()

Both are versioned together and released from the spec — see how the clients are generated and published.

Start from an example app

Full working apps you can run and read, each wired to the published client:

TypeScript example (Next.js)A camera-control web UI: connect, adjust settings, live view, shoot, browse the SD card.

Python exampleA notebook/data-collection script: connect, snapshot properties, pull live-view frames.

Generate for another language

TypeScript and Python are published above — for anything else, point an OpenAPI generator at the spec. A few examples:

# Add the Swift OpenAPI Generator plugin to Package.swift, drop the spec at
# Sources/<Target>/openapi.yaml, then build.
swift package plugin --allow-writing-to-package-directory generate-code-from-openapi

dotnet tool install --global Microsoft.OpenApi.Kiota
kiota generate -l CSharp \
  -d https://crsdk.github.io/alpha-sdk-api/api-reference/openapi.yaml \
  -o ./CameraClient

# openapi-generator supports ~50 languages; swap the -g target.
npx @openapitools/openapi-generator-cli generate \
  -i https://crsdk.github.io/alpha-sdk-api/api-reference/openapi.yaml \
  -g go \
  -o ./camera-client

Pin the specification file into your repository rather than fetching it at build time if you want reproducible builds — it is a single YAML file.

What the API looks like

The operations are grouped by tag, and a generated client will mirror that grouping:

server        health, status, logs
cameras       list, connect, disconnect, getConnectionStatus
properties    get, set, getAll, getPriorityKey, setPriorityKey
actions       shutter, halfPress, afShutter, zoom, focusNearFar, movieRec
liveView      enable, disable, getStatus, start, stop, getFrame
sdCard        list, download, downloadThumbnail, downloadScreennail
settings      download, upload, list, importLut

Two things sit outside what a generator will give you, because they are not plain request/response operations:

Server-Sent Events — the two event streams are long-lived and most generators will not produce anything usable for them. Consume them with native EventSource (browser) or httpx.stream (Python). See the SSE recipe.
Discovery, reconnect and lifecycle handling — application concerns rather than API surface. The recipes below cover the usual patterns.

Running the server

Every client, generated or not, talks to the REST server running on the machine the camera is attached to.

Run the serverBuild and run the server, and the endpoints it exposes for health, logs and shutdown.

Recipes

Patterns that sit outside generated code. Each works against the REST API directly, so they apply whatever language you generate for.

SSE event consumerReact in real time to propertyChanged, downloadComplete, transferProgress.

Live-view JPEG pollingPull a frame every ~66ms and render it.

Server subprocessSpawn and supervise the native server from your own runtime.

Discovery + reconnectPoll /api/cameras, track which is connected, handle hot-plug.

Retry + backoffExponential backoff for flaky connect and SD card calls.

React hookuseCamera() — bind one camera's connection and property state.