> For the complete documentation index, see [llms.txt](https://docs.unitlab.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.unitlab.ai/release-notes/unitlab-python-sdk-3.0.0.md).

# Unitlab Python SDK 3.0.0

{% hint style="info" %}
**Released:** July 27, 2026 · **Scope:** Python SDK, CLI, authenticated API transport · **Audience:** developers, data engineering, ML operations, platform engineering, and automation owners
{% endhint %}

### Summary

Unitlab 3.0.0 provides one public Python package and console interface for current Unitlab platform automation. The package metadata requires Python 3.10 or newer and installs the `unitlab` console command. The current codebase uses `httpx`, `tqdm`, and `typer` as runtime dependencies.

### Public resource coverage

The package exports `UnitlabClient` and public handles for Projects, Data Units, Batch Queues, Assets, folders, cloud storage, Data Groups, datasets and dataset versions, embedding spaces, ontologies, workflow stages and tasks, releases, uploads, and attached sources.

Typed public results include asset-upload results, attach previews and results, cloud entries, processing status, upload failures, and resource-specific dataclasses. Raw payloads remain available for diagnosis and forward-compatible inspection, but production business logic should prefer typed fields.

### Ontology and workflow automation

The public ontology builder includes object classes, classifications, shapes, radio, checklist, text, and numeric attributes, nested conditional logic, and dynamic values where supported. Workflow handles support stage lookup, task enumeration, claim, assignment, release, priority, submit, approve, reject, skip, move, bulk operations, and task history according to the project’s configured workflow.

### Processing and failure behavior

Uploads, cloud imports, attachments, and other asynchronous operations can create Batch Queues. Request acceptance is not processing completion. Callers must retain the Batch Queue identifier, wait with an explicit deadline, and inspect item-level failures even after active processing reaches zero.

The package exposes distinct categories for authentication, validation, not-found, permission, subscription, network, request-timeout, and processing-timeout failures. A request timeout can occur after the server accepted a mutation; inspect remote state before retrying. A processing timeout includes the last observed state so monitoring can continue without guessing.

### CLI behavior

The command tree covers configuration, projects and Data Units, Batch Queues, Assets and folders, datasets and versions, workflow tasks, releases, ontologies, cloud storage, grouping, and custom embedding spaces. Use machine-readable JSON for scripts and continuous integration. Human-oriented output is concise and may change for readability.

State-changing commands return a non-zero status on validation or API failure. A project upload also reports partial file failure through a non-zero status even when some files succeeded; preserve the created Batch Queue and accepted file identifiers before deciding whether to retry failed inputs.

### Adoption checklist

* [ ] Pin `unitlab==3.0.0` in the tested production environment.
* [ ] Confirm Python 3.10 or newer and verify the package and console entry points resolve the same environment.
* [ ] Use a least-privilege workspace-owned service identity and an approved secret store.
* [ ] Exercise list and detail operations before mutations.
* [ ] Test project creation, upload or cloud import, processing waits, source attachment, workflow actions, ontology handling, embeddings where used, and release creation.
* [ ] Verify validation, permission, request-timeout, processing-timeout, and partial-failure paths.
* [ ] Validate one generated release in the real downstream consumer.
* [ ] Record the SDK version, application version, correlation IDs, stable resource IDs, counts, duration, final state, and redacted errors.

### Compatibility and risk

Version 3.0.0 should be treated as an explicit application dependency. Do not upgrade production jobs only because an unpinned environment resolves a newer distribution. Test the actual methods and CLI subcommands used by the application against representative data and current workspace permissions.

Automation must not assume that names are stable identifiers, that request completion means server processing completion, that an empty model response is success, or that a timed-out mutation was rejected. These assumptions create duplicate resources, missing work, and unreproducible deliveries.

### Verification

An adoption is complete when the pinned package reports version 3.0.0, a representative end-to-end job reaches the expected resource states, no failed Batch Queue rows remain unexplained, workflow transitions match the configured stage graph, and a release is accepted downstream.

### Recovery

If validation fails, stop rollout, preserve returned resource and Batch Queue IDs, inspect server state, isolate the failing operation, and keep production pinned to its previously tested environment. Do not delete or repeat accepted resources as a cleanup shortcut. Reconcile remote state and use the documented project, dataset, workflow, or release lifecycle with an accountable owner.