Skip to main content
Both SDKs are generated from the same OpenAPI contract that produces the API reference, so every operation, field, and error there exists in both, with the same semantics. Method names follow the operation ids: sessions.run_session / sessions.runSession, secrets.create_secret / secrets.createSecret, and so on.

Authentication

Constructed with no security argument, both clients read ALBUS_API_KEY_AUTH and ALBUS_BEARER_AUTH from the environment. Note these are not the CLI’s ALBUS_API_KEY — see Authenticate.

Responses

An operation with response headers you need returns them alongside the body: response.result is the parsed body and response.headers the headers. That is how you read the effective idempotency key of a run:

Errors

Every non-2xx status raises a typed error carrying status_code, message, and body (errors.AlbusError and its subclasses in Python). Handle at least 423, 429, and 504 — see failure modes. Both SDKs retry 429, 500, 502, 503, and 504 when you pass a retry config. Be careful combining that with a long-polling run: a 504 retry is a new request, so supply an idempotency key or you will start a second invocation.

Versions

The published SDK version that matches the current API reference is recorded in the release policy. SDKs are released after the API they document is deployed, never before.