Build on CloakAPI

CloakAPI is API-first privacy infrastructure. You don’t have to use our consumer surfaces (chat, extension, desktop) — you can build your own app or skin on top of CloakAPI and have your end users inherit the same guarantee: sensitive data is tokenised on their device, the gateway is a blind relay, and answers can carry a receipt you can check against the published JWKS. The release register (release-integrity.json) is an unsigned SHA-256 catalogue — do not describe it as a signed proof.

This section is for the builder: the developer or company shipping a product on CloakAPI. If you just want to use CloakAPI yourself, start with the Quickstart instead.

The proposition

A product built on CloakAPI can offer its own users verifiable privacy it did not have to invent:

Client-side tokenisation — personal data is replaced with realistic surrogates on the end-user’s device, before anything is sent.
Blind relay — CloakAPI’s gateway forwards traffic to the upstream model (Anthropic, OpenAI, Google Gemini, xAI, DeepSeek). It does not inspect content, keeps none of it apart from a 24-hour idempotency cache (below), and holds no re-identification map.
Receipts — when a receipt is issued, it can use an ecdsa-p256-sha256 OpenReceipt v3 envelope checkable against a public key. The release register (release-integrity.json) is unsigned — do not describe it as a signed proof.

You inherit all three by embedding one of the platform build-surfaces (below) — you do not re-implement the tokeniser, the detection rules, or the crypto.

The honest wording (read this before you write marketing copy)

CloakAPI’s guarantees are deliberately precise. If you build on the platform, your copy must stay inside the same lines — a “Verified by CloakAPI” build is held to them.

“CloakAPI does not inspect content, and keeps none of it apart from a 24-hour idempotency cache.” This is true on every integration. The gateway is a pure relay with no server-side detection engine and no content persistence in its database or logs. One bounded exception: when a caller sends an Idempotency-Key, the gateway caches that call’s (tokenised) response in Redis for up to 24 hours so a retry replays the same bytes; the request body is kept only as a SHA-256. You may say this about any integration.
“No raw PII reaches CloakAPI.” This holds whenever the client tokenised — which every CloakAPI-provided client surface (proxy, SDK, self-hosted MCP, starter-kit) does automatically before egress; see below. There is no server-side tokenise path that could re-introduce raw PII on our side. The only way raw PII could reach the gateway is a raw REST call you chose not to tokenise first — and even then the gateway does not inspect it. For unqualified copy, prefer this form: “CloakAPI does not inspect content, and keeps none of it apart from a 24-hour idempotency cache.”

Client-side tokenisation only

CloakAPI supports one integration model, and it is the strong one:

Client-side embed (the whole platform story). Tokenisation runs on the end-user’s device before data leaves it — via the drop-in proxy, an SDK/WASM/ FFI, the self-hosted MCP server, or the starter-kit. PII the on-device detector finds is tokenised before it reaches your server or CloakAPI; detection is best-effort, so undetected text is sent as written. This is the only way builds integrate.
There is no server-side tokenise mode. CloakAPI does not offer an endpoint that accepts raw text and tokenises it on our servers — that would break the blind-relay guarantee. The gateway never detects, tokenises, or reconstructs content; it is a relay that forwards what the device sent, which is tokenised text plus anything the on-device detector missed (see our platform architecture decision, ADR-0014). Because there is no server-side tokenise path, “CloakAPI does not inspect content, and keeps none of it apart from a 24-hour idempotency cache” holds on every integration; “no raw PII reaches CloakAPI” holds whenever the client tokenised — automatic on every CloakAPI client surface, and your responsibility on a hand-rolled raw REST call.

Enforcement vs detection — two different guarantees

These are treated differently on purpose, and your copy should reflect it:

Enforcement — “can a builder send raw text past the tokeniser?” On the sealed, gateway-locked client surfaces (the drop-in proxy, the SDKs, and the self-hosted MCP) this is pushed to ~100%: the engine is sealed, the gateway holds key-custody, and a gateway version/hash gate means the only door to the relay is through the current, allowlisted tokeniser. The one exception is a raw REST call you assemble yourself — there the gateway does not tokenise on your behalf, so an un-tokenised request to the relay inference routes is refused rather than forwarded (fail-closed on that request; see Choose your integration). It is still a blind relay — CloakAPI does not inspect that content — but “no raw PII reaches CloakAPI” then depends on you tokenising first. This is the strong guarantee on the locked surfaces.
Detection — “did the tokeniser catch every piece of PII?” This is best-effort and fail-closed. Natural-language PII detection is inherently probabilistic, so it is accepted to be asymptotically below 100%. No crypto fixes this. The engine fails closed on high-stakes secrets (it refuses to send rather than risk a leak) — but you must never claim “100% safe” or “100% detection”. That claim is itself a user-safety hazard.

Next steps

Choose your integration — REST, self-hosted MCP, SDK (8 languages), drop-in proxy, or the open starter-kit, with a minimal quickstart for each.
Verify + get the badge — run the conformance suite and display “Verified by CloakAPI”.
Onboard & bill your users — provision your end-users as full CloakAPI accounts under your own app_id, and bill them on their metered wallet or your own subscription.
Builder pricing — the markup model for building on CloakAPI.