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 every answer carries a signed receipt anyone can verify.

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 never inspects or stores content, and it holds no re-identification map.
Signed receipts — every response is signed with an ecdsa-p256-sha256 OpenReceipt v3 envelope, verifiable offline months later against a public key. Your users can check the evidence themselves; they don’t have to trust you or us.

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 never inspects or stores content.” This is always true. The gateway is a pure relay with no server-side detection engine and no content persistence. 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 never inspects or stores it. For unqualified copy, prefer the always-true form: “CloakAPI never inspects or stores content.”

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. Raw PII never egresses to your server or to CloakAPI. 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 pure relay that only ever sees tokens (see our platform architecture decision, ADR-0014). Because there is no server-side tokenise path, “CloakAPI never inspects or stores content” holds unconditionally 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 can’t force client-side tokenisation, so an un-tokenised request is relayed as-is (fail-open on that request, never tokenised on our servers; see Choose your integration). It is still a blind relay — CloakAPI never inspects or stores 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.