SDKs
The Lattix SDK family — Rust, Go, and Python libraries for embedded enforcement against the platform control plane. Metadata-only, consistent surface across languages.
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, and they expose the same surface:
| 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.
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.
The eight operations
Every binding exposes the same eight methods. Each maps 1:1 to a /v1/sdk/* route 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 (only in SDK-client-credentials mode). |
protection_plan | Takes workload + resource metadata, returns a local-enforcement plan for a proposed protect / access / rewrap operation. |
policy_resolve | Takes workload + resource metadata, returns authorization and handling guidance. |
key_access_plan | Takes metadata for a wrap / unwrap / rewrap flow, returns how the SDK should perform local cryptographic work. |
artifact_register | After local protection, registers the resulting protected-artifact digest, profile, and references. |
evidence | Ingests metadata-only evidence events tied to protected artifacts and policy decisions. |
All request and response types are metadata structures. Neither the request nor the response carries plaintext content. The SDK returns guidance such as protect_locally, send_plaintext_to_platform: false, artifact_profile, and required_scopes — the application uses that guidance to enforce the decision at the workload.
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 profiles:
tdf— the Trusted Data Format envelope.envelope— a generic envelope wrap.detached_signature— a detached signature over an artifact stored elsewhere.
These are selectable per operation. The bootstrap response lists which profiles the deployment supports.
Picking a language
- Rust is the canonical core. Use it when you want the minimum dependencies, the smallest binding surface, and access to the native library directly.
- 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.