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.

In practical terms, teams use the SDKs for four value streams:

Protect new data before it leaves the process.
Open protected data only when tenant policy and key authorization allow it.
Rewrap or rotate access without shipping plaintext to the platform.
Register artifacts and emit evidence so every tenant-bound action is traceable.

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 eight 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, control-plane domains, and published auth configuration.
`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.

Common application flows

Flow	Typical SDK/API sequence	Value
Discover who the caller is	`capabilities` or `whoami`	Confirm tenant, principal, scopes, and the active auth contract before doing work.
Protect new content locally	`protection_plan` → `policy_resolve` → `key_access_plan` → local protect helper → `artifact_register` → `evidence`	Keep plaintext and keys in-process while still enforcing centrally managed policy.
Access protected content locally	`policy_resolve` → `key_access_plan` → local access helper → `evidence`	Allow tenant-bound use of protected artifacts without turning the platform into a plaintext service.
Rewrap or rotate access	`protection_plan` or `policy_resolve` → `key_access_plan` → local rewrap helper → `artifact_register` or `evidence`	Change key references or authorization context without re-ingesting raw content.

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

Public SDK integrations use bearer tokens. Obtain a token from the published OAuth/OIDC issuer, then pass it to the SDK and let the SDK attach it to every request.

Read capabilities or bootstrap first; the returned auth_configuration block tells the caller which issuer, audience, and proof-of-possession contract are active for the deployment. When proof_of_possession is mtls, the runtime still needs the client certificate at the public edge so the access token is sender-constrained.

Do not build new public integrations against the retired credential-exchange flow. The public api.lattix.io contract no longer exposes that route.

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.md and docs.rs/sdk-rust (published per release).
Go — the module's README.md at github.com/LATTIX-IO/sdk-go-public and the Go package reference on pkg.go.dev.
Python — the package's README.md on PyPI and the Pydantic model definitions under lattixsdk.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.

On this page