Platform API

The Lattix Platform API is the HTTP control plane that the SDKs speak to. It is deliberately metadata-only on the wire: protected data never transits the platform API for routine protect / access / rewrap workflows. The API's job is to answer identity, policy, key-authorization, registration, and evidence questions so applications can enforce the decisions locally.

Most customers should use an SDK rather than calling the HTTP surface directly. If an SDK for your language is not yet available, or you have an orchestration layer that already owns its HTTP client, the routes on this page are the supported integration surface.

Interactive reference

For a browsable view of every route — tags, parameters, request and response shapes — open the API Explorer. It is generated from the same OpenAPI document the SDKs are built from, so it stays in sync with every release.

The spec itself is published at /openapi/sdk-control-plane.yaml if you want to feed it to a code generator or a linter.

Base URL

The production base URL is https://api.lattix.io. Deployments in other environments publish their own base URL through your operational runbook.

Every public route documented here lives under the /v1/sdk/* path prefix. Other /v1/* route families exist in the platform, but they are not part of the supported external contract.

What teams use it for

Most integrations use the SDK/API for four concrete flows:

• Protect new data locally — ask the platform for policy and key-handling guidance, then encrypt or sign inside your own process.
• Access protected data locally — resolve whether a caller is allowed to open a protected artifact, then decrypt or verify in-process.
• Change access without moving plaintext — rewrap or rotate protected artifacts under new key references or authorization decisions.
• Prove governance happened — register protected artifacts and emit evidence so tenant-bound actions are traceable after local enforcement.

That is why this API is a control plane, not a generic data plane. It answers identity, policy, key-authorization, registration, and evidence questions so your workload can enforce the result locally.

The eight public routes

All eight routes are authenticated SDK routes. On the public api.lattix.io path, callers obtain OAuth/OIDC access tokens from the published issuer, present them as bearer tokens, and satisfy the declared proof-of-possession contract. Today that public PoP contract is mtls.

Metadata-only stance

The contract intentionally does not accept raw document bytes, raw prompt text, or other plaintext payloads as part of routine SDK protection workflows. Every request body is a metadata structure describing workload, resource, and operation. Every response body is a metadata structure describing caller identity, decisions, and an execution plan.

The bootstrap response makes this stance explicit: it returns plaintext_to_platform: false to confirm that plaintext is out of contract.

Applications perform protection and decryption locally. The API decides whether those operations are allowed, provides the guidance needed to carry them out, and ingests the resulting evidence. The fastest way to think about it is: the SDK handles bytes and keys locally; the API supplies identity, policy, key, registration, and evidence control-plane decisions.

Request and response conventions

• Content-Type — every request and response uses application/json with UTF-8 encoding.
• Identifiers — tenant, principal, and subject identifiers are opaque strings. Do not parse them.
• Enums — use the lowercase snake_case forms documented per endpoint (protect, access, rewrap; wrap, unwrap, rewrap; tdf, envelope, detached_signature; protect, access, rewrap, deny).
• Timestamps — caller-supplied timestamps (e.g. occurred_at on evidence) are RFC 3339 strings.
• Maps — attribute maps are { string: string } and are never schema-typed beyond that at the contract level; use them for tags the platform does not interpret as first-class fields.
• Artifact identity — registration and evidence flows may include artifact_kind, artifact_cid, and artifact_merkle_root_cid when the caller already has a stable content identifier.
• Nullability — fields that are optional in the contract are marked nullable: true in the OpenAPI and correspond to optional / omittable fields in each SDK.

Error envelope

Every error response uses the same JSON shape:

{
  "error": {
    "code": "string",
    "message": "string"
  }
}

The code is a stable machine-readable identifier the client can branch on; the message is a human-readable description. No stack traces, internal service names, or internal paths are returned in error bodies.

Common statuses:

Authentication

The public API uses bearer tokens obtained from the published OAuth/OIDC issuer. Read capabilities or bootstrap first: their auth_configuration block tells you which issuer, audience, and proof-of-possession contract are active. When proof_of_possession is mtls, the public integration should be understood as a sender-constrained bearer flow, not a replayable bare bearer token.

Private deployments may also support trusted-header ingress modes, but those are not part of the public api.lattix.io integration contract.

See Authentication for the full model, including issuer discovery, tenant binding, and scope handling.

Health

/healthz and /readyz are the documented health endpoints for orchestration probes. They return minimal status and do not require authentication.

OpenAPI

The machine-readable contract for this surface is published as an OpenAPI 3.0 document in the lattix-platform-api source repository at openapi/sdk-control-plane.yaml. The Rust, Go, and Python SDKs are all aligned to that contract. If you are generating your own client, use the OpenAPI document as the source of truth rather than transcribing the summary tables on this site.

Relationship to other pages

• SDKs — the Lattix-maintained clients for this API.
• Zero Trust Fabric — where the API sits in the overall architecture (control plane, not data plane).
• Hierarchical Key Model — how key-access guidance maps to KEK/DEK/KAS semantics at the caller.