Skip to content

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.

Terminal window
npm install alyt-sdk@8.0.0
import { 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.

Terminal window
pip install alyt-sdk==8.0.0
import os
import httpx
from alyt_sdk import AuthenticatedClient
from 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.

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.

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.

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.

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.

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.

Last updated