SDKs
Both SDKs are generated from their released API contract: operations become methods and shapes become types. The live reference can include newer operations while an SDK release is being reviewed. Compatible additions increment the minor version; compatible prose corrections increment the patch. Removed operations, stricter requests, incompatible response alternatives or changed public generated types require a major release and migration review. The changelog lists published changes.
The current published version is 8.0.0 for both TypeScript on npm and Python on PyPI.
Both clients cover 300 public operations, retaining the previous 293 and adding
La Marzocco coverage, equipment reads and local setup. Version 8 adds a
LA_MARZOCCO routine response alternative; review the
migration notes when upgrading exhaustive protocol
switches. Earlier migration notes remain available below.
For the supplied encrypted LAN MCP adapter, install
alyt-sdk[local-mcp]==8.0.0 on Python 3.11 or newer. This optional extra supports
July 2026 MCP and the retained legacy revisions without adding a radio dependency
to ordinary HTTP SDK installations. See local MCP and Matter
for connection, authorization, transport and device-support limits.
Get started walks through creating an app and its credentials;
Application credentials explains token exchange.
TypeScript
Section titled “TypeScript”npm install alyt-sdk@8.0.0import { createAlyt } from "alyt-sdk";
const alyt = createAlyt({ appId: process.env.ALYT_APP_ID!, appSecret: process.env.ALYT_APP_SECRET!,});
// Every call answers { data, error, response }; a refusal carries the server's words.const rooms = await alyt.roomsList({ query: { tenantId, propertyId } });for (const room of rooms.data?.items ?? []) console.log(room.name);
// Turn on a sandbox virtual light using its device ID.await alyt.devicesCommand({ path: { id: deviceId }, query: { tenantId }, body: { command: "set", payload: { capability: "light", key: "power", value: true } } });The App ID/secret form is for server code. It exchanges credentials for a short-lived token, shares concurrent exchanges and renews before expiry. Keep both values in your server secret store. You can also pass { accessToken }, or retain { apiKey } for a legacy bearer key.
Method names are <noun><Verb> from the operation: devicesList, integrationsConnect,
endpointsCommand. Each one’s operationId is on the reference page. The client is a
fetch client with no other dependency; pass your own fetch or baseUrl to createAlyt
for a self-hosted platform.
Python
Section titled “Python”pip install alyt-sdk==8.0.0import osimport httpxfrom alyt_sdk import AuthenticatedClientfrom alyt_sdk.api.properties import properties_list
token_response = httpx.post( "https://developers.alyt.com/api/v1/developers/oauth/token", json={"grant_type": "client_credentials", "client_id": os.environ["ALYT_APP_ID"], "client_secret": os.environ["ALYT_APP_SECRET"]}, timeout=10,)token_response.raise_for_status()client = AuthenticatedClient( base_url="https://developers.alyt.com/api", token=token_response.json()["access_token"],)page = properties_list.sync(client=client, tenant_id=TENANT)for prop in page.items: print(prop.name)The Python client is generated without an automatic token manager. Exchange again before expires_in elapses (at most five minutes), and construct a new authenticated client. The base URL ends in /api: generated operation paths already include /v1.
A DEV key (alyt_dev_…) acts in your sandbox as its admin. A LIVE key (alyt_live_…) is
issued after ALYT approves your connector. Deploy the approved
version and confirm release before publication. A LIVE credential acts only in homes
that installed that connector, for its own things; approval alone grants no home access. Both go in
Authorization: Bearer; the SDK sets the header for you.
Regenerating
Section titled “Regenerating”The packages are published by the platform’s own pipeline from the committed contract
(docs/surface/openapi.json). PyPI carries a workflow attestation; npm provenance is disabled while the source repository is private. To generate a client for another language,
take /api/v1/openapi.json to the generator of your choice; the
contract carries x-alyt-scope on every operation, the scope a key needs to call it.
Migrating from SDK 7
Section titled “Migrating from SDK 7”Version 8.0.0 adds LA_MARZOCCO as a routine device response alternative.
Update exhaustive protocol switches to handle it. The six previous alternatives,
all 293 previous operations and previous named TypeScript exports remain available.
The seven new operations cover connector capabilities, equipment reads, local
setup metadata, finite discovery and authenticated enrollment progress. Commands,
rooms and routines still use their existing APIs and household permissions.
An SDK binding does not qualify a machine’s Bluetooth connection or grant a
capability the machine does not report. See La Marzocco.
Migrating from SDK 6
Section titled “Migrating from SDK 6”Version 7.0.0 describes up to 255 authored routine steps and optional
excludeThingIds on room actions. Update strict response validators that assume
30 steps, and preserve the exclusion list when editing an existing action.
An explicit empty list clears the selection; omitting an existing list is refused.
The server still checks expanded actions and the assigned hub’s actual capacity
before saving, so 255 authored steps are not a guarantee that every expansion fits.
Remote-button cells and the qualified model subset retain their separate limits.
All 293 operations and previous named TypeScript exports remain available.
Migrating from SDK 5
Section titled “Migrating from SDK 5”Version 6.0.0 adds GOVEE as a routine device response alternative in
GET /v1/properties/{propertyId}/routines/local. Add that case to exhaustive
protocol switches. The five earlier alternatives and existing operation names
remain unchanged. Local and cloud Govee controls use the same capability-based
device and routine APIs; the connector handles provider-specific value formats.
Migrating from SDK 3.0.0
Section titled “Migrating from SDK 3.0.0”Version 4.0.0 adds button-record operations and updates the fluid
curtain-calibration contract. Calibration movement uses move.left and
move.right with a selected phase.open or phase.closed; the older
move.open, move.close, teach.open and teach.closed request values are not
aliases. Calibration responses can include confirming, and calibrated state can
be unknown rather than false. A client must wait for the correlated saved result
before treating calibration as complete.
Routine action kinds remain available, but component deduplication changes some
anonymous generated type and module names. Use an operation’s response type and
narrow actions by their kind discriminator instead of importing a numbered
RoutinesListItemDoItemOption* name. In Python, construct models with keyword
arguments; new optional fields can change positional argument order. Update
strict response validators for button triggers and newly supported local hub
things. A successful import alone does not verify that an anonymous model still
means the same action. Upgrade and test any code that imports generated model
names or validates routine and calibration responses strictly.