SDKs
The Lattix SDK family — Rust, Go, and Python libraries for metadata-only control-plane calls plus local embedded-protection helpers.
The Lattix SDKs let an application protect and access data locally while the platform handles identity, policy, key authorization, and evidence. They are the embedded enforcement path for the Zero Trust Fabric.
Three language bindings are available. They share the same public control-plane contract and package the same local embedded-protection model, while exposing language-idiomatic method names:
| Language | Package | Transport |
|---|---|---|
| Rust | sdk-rust on crates.io | Native HTTPS client |
| Go | github.com/LATTIX-IO/sdk-go-public | CGO bridge to the Rust core |
| Python | lattix-sdk-python on PyPI (import lattixsdk) | ctypes bridge to the Rust core, exposed as async |
Rust owns the HTTP behavior, contract serialization, and platform semantics. Go and Python are thin, typed wrappers over the same native core, so the three bindings stay behaviorally consistent.
Core control-plane operations
Each SDK ships the same nine public control-plane operations. These map to the /v1/sdk/* HTTP routes documented under Platform API → Endpoints.
| Operation | What it does |
|---|---|
capabilities | Returns caller identity, active authentication mode, and which platform domains are configured for this deployment. |
whoami | Returns the resolved tenant, principal, subject, and scopes for the caller. |
bootstrap | Describes the embedded-enforcement model, supported operations, supported artifact profiles, and control-plane domains the SDK may need. |
exchange_session | Exchanges SDK client credentials for a short-lived bearer token when client-credentials mode is enabled. |
protection_plan | Takes workload + resource metadata and returns a local-enforcement plan for a proposed protect / access / rewrap operation. |
policy_resolve | Takes workload + resource metadata and returns authorization and handling guidance. |
key_access_plan | Takes metadata for a wrap / unwrap / rewrap flow and returns how the SDK should perform local cryptographic work. |
artifact_register | After local protection, registers the protected-artifact metadata, including digest/profile/reference fields. |
evidence | Ingests metadata-only evidence events tied to protected artifacts and policy decisions. |
The HTTP contract stays metadata-only even when an SDK is also using local helper APIs to work with bytes, keys, or detached signatures in-process.
Metadata-only, by design
The SDKs do not transport plaintext payloads to the Lattix platform for routine protection flows. Applications protect data locally; the SDK calls the platform to:
- discover caller identity and capabilities,
- resolve policy from workload and resource metadata,
- obtain key-handling guidance for wrap / unwrap / rewrap operations,
- register protected-artifact references after local enforcement,
- emit evidence events after local policy decisions.
This is the embedded-enforcement model described in the Platform Overview. The authoritative machine-readable contract for the SDK control plane is published as OpenAPI in the lattix-platform-api repository.
Local embedded-protection helpers available now
In addition to the shared control-plane calls, the current SDK releases also expose local helper APIs for embedded enforcement. These helpers keep artifact bytes and key material inside the caller process and use the control plane for identity, policy, key guidance, registration, and evidence.
| Helper family | Rust | Go | Python |
|---|---|---|---|
| Local planning + CID binding | prepare_local_protection, generate_cid_binding | PrepareLocalProtection, GenerateCIDBinding | prepare_local_protection, generate_cid_binding |
| Envelope artifacts | Protect / access / rewrap helpers | Protect / access / rewrap helpers | Protect / access / rewrap helpers |
| TDF artifacts | Protect / access / rewrap + attribute update helpers | Protect / access / rewrap + attribute update helpers | Protect / access / rewrap + attribute update helpers |
| Detached signatures | Sign / verify helpers | Sign / verify helpers | Sign / verify helpers |
| Managed key providers | Builder-registered providers | Options.ManagedSymmetricKeyProviders | managed_symmetric_key_providers= |
The exact method names follow each language's normal conventions. The package README and generated API reference for each SDK remain the authoritative place for exhaustive per-language signatures.
Authentication
Each SDK supports two authentication modes:
- Bearer token — the caller supplies a pre-existing token and the SDK attaches it to every request.
- SDK client credentials — the caller supplies a
client_id/client_secret, and the SDK exchanges them for a short-lived bearer token on first use, caching and refreshing it automatically.
Which mode to use is a deployment decision. See Platform API → Authentication for the end-to-end model.
Artifact profiles
Protection operations refer to artifacts using one of three public profiles:
tdf— the Trusted Data Format envelope.envelope— a generic envelope wrap.detached_signature— a detached signature over an artifact stored elsewhere.
The control plane reports which profiles a deployment supports. The current SDK releases also ship local helper APIs for all three profiles.
Picking a language
- Rust is the canonical core. Use it when you want the minimum dependencies, the native builder surface, and direct access to the full local-helper feature set.
- Go is the right choice for sidecars, gateways, and service-mesh enforcement. It depends on the Rust native library installed alongside the Go binary.
- Python is the right choice for data pipelines, notebooks, and orchestrated workloads. The API is async and built on Pydantic models that mirror the platform contract.
The three SDKs are version-aligned. When the Rust core is released, the matching Go and Python packages are released against the same control-plane contract.
Where to find per-language reference
Detailed per-language API reference lives with each SDK package and is intentionally not duplicated here:
- Rust — the crate's
README.mdand docs.rs/sdk-rust (published per release). - Go — the module's
README.mdat github.com/LATTIX-IO/sdk-go-public and the Go package reference on pkg.go.dev. - Python — the package's
README.mdon PyPI and the Pydantic model definitions underlattixsdk.models.
This site covers the conceptual model, the quickstart for each language, and the HTTP control-plane contract under Platform API.
Quickstarts
Relationship to other concepts
- The SDKs are how applications participate in the Zero Trust Fabric — specifically as the local enforcement path on each node.
- They call the Platform API to resolve policy and obtain key-handling guidance.
- Key-handling guidance is interpreted against the Hierarchical Key Model.
- Protected artifacts are registered and evidence is emitted against the Immutable Ledger.