Skip to main content
Identify and the rest of the workbench authenticate with a workspace API key. Loom accepts that same key on the relay path, or a short-lived session token on the direct path. Those credentials prove who is calling us. A separate secret proves a call came from us. The trust model lays out all four and which ones you need.

API keys

Create and revoke keys on the Developers page. Each key is a name, a public id (key_…), and a secret (sk_…).
  • The secret is a bearer token. Treat it like a password. Never put it in a browser or commit it.
  • The public id goes in a direct session token’s iss claim. It identifies the key; it authorizes nothing on its own.
  • A revoked key stops working immediately.
We charge outcomes, not requests: an identified result on Identify, a closed run on Loom that isn’t a platform failure. Verifying your email address starts the workspace with $20 of credit.

Loom: two ingress modes

The credential’s form selects the mode. A JWT bearer is direct. Anything else is a relay workspace API key. You do not declare a mode. Same trust model on both paths: we hold your public key, we never mint identity, and every tool call to your backend is signed. Which one to pick, and why: Choosing an integration.
A relay API key can assert any subject in your workspace. Keep it server-side — if a browser or mobile client needs to talk to us, that is direct, not a shared key.

MCP: a third credential

An agent reached from a user’s own AI client authenticates with neither of those. The client holds an OAuth access token it obtained itself, and the user’s identity came from your own login. You issue nothing and verify nothing at that door — see MCP export.

Verifying our requests

Every call we make to your backend — a tool call, a relay mint, the health probe — carries a Patchwork-Signature header, so you can prove it is really us before acting on it.
v2 is HMAC-SHA256, keyed by your workspace request secret, over exactly:
A literal v2., uppercase method, the path with the query string exactly as it arrived (no host, no sorting, no re-encoding), and the base64 of the SHA-256 digest of the raw request body. No query means no ?. To check it: recompute the HMAC, compare in constant time, and reject anything whose t is more than 300 seconds old. Full verification code, secret rotation (verify against your current and previous secret), and the /patchwork/up health proof: Signing and verification.
The request secret is not your private signing key. It is symmetric and shared, and it only ever verifies traffic coming from Patchwork. Your signing key is private, stays on your servers, and signs the session tokens you issue. Side by side.

Unauthorized requests

Requests without a valid key or token return 401 and an error envelope. Send Authorization on every call.