Platform API

The Lattix Platform API is the HTTP control plane that the SDKs speak to. It is deliberately metadata-only: protected data never transits the platform API for routine protect / access / rewrap workflows. The API's job is to answer identity, policy, key-authorization, 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 route documented here lives under the /v1/sdk/* path prefix. Other /v1/* route families exist for internal service-to-service traffic and are not a supported public contract.

The eight routes

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.

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.
• 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 API supports two authentication patterns:

• Bearer token — the caller attaches a pre-issued JWT in the standard Authorization: Bearer ... header.
• SDK client credentials — the caller exchanges a client_id / client_secret at /v1/sdk/session for a short-lived bearer token.

See Authentication for the full model, including 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 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.