Skip to content
Proof of ThoughtBuild

Platforms and keys

View .md

A platform is your product as Proof knows it. Everything you create through the API belongs to one platform: its users, documents, agents, seals and webhook endpoints. Platforms never see each other’s data. A user usr_5Kq2Lm8R on Acme Notes and a user usr_5Kq2Lm8R on another platform are two unrelated people.

Proof of Thought, our own app, is a platform too. It uses the same API and the same keys you do.

Console settings

Section titled “Console settings”

You create a platform in the console. Its settings decide how Proof presents and protects your product.

Setting What it does
Name Shown wherever Proof speaks for you, most visibly on seal pages: “Written in Acme Notes”.
Slug A short, permanent id, such as acme. It is part of your MCP address, https://mcp.proof.exalto.ai/acme, so pick it once.
Embed origins The origins allowed to show the editor, such as https://acme.com. The editor refuses to load in a frame anywhere else.
Consent URL The page on your site where people approve an agent, such as https://acme.com/proof/connect. See Agents.
Reader URL The page on your site where readers of private seals sign in. See Seals.
Document URL Where your product shows a document, such as https://acme.com/docs/{document}, for links between documents and in agents’ answers.
Agent tools Tools of your own that agents get beside Proof’s. See Add your own agent tools.
Webhook endpoints Where Proof sends events. You can also manage these through the API.
Keys Your secret keys, for test and live mode.

Everything but the slug and keys can be set from your server too, with PATCH /v1/platform and PUT /v1/platform/tools. The consent, reader and document URLs and the agent tools are per mode.

Secret keys

Section titled “Secret keys”

Your server calls the API with a secret key in the Authorization header:

Terminal window
curl https://api.proof.exalto.ai/v1/users/usr_5Kq2Lm8R \
  -H "Authorization: Bearer sk_test_51Hx…"

A secret key can do anything on your platform, including start an editor session as any of your users. Keep it on your server. The browser never needs it: it gets a short-lived session token for one document instead.

Every key has a public id, such as key_3Fq9, shown beside it in the console. Proof records which key started each writing session, and a seal lists the key ids behind it in attested_by. If a key ever leaks, that record tells you and anyone checking a seal which sessions it could have touched. The trust model explains why this matters.

Test and live mode

Section titled “Test and live mode”

Each platform has two sets of keys and two separate sets of data.

  • Test keys (sk_test_…) see only test objects. Use them in development and CI. Test seals get codes beginning with T, and their pages say “Test seal”, so they can’t be passed off as real.
  • Live keys (sk_live_…) see only live objects. Live seals are the ones your users share.

Nothing moves between the two modes. A document created with a test key can’t be opened with a live key, and the same external_id in each mode is two separate users, with different Proof ids. Webhook endpoints are set per mode too.

Rolling a key

Section titled “Rolling a key”

Roll a key in the console when someone who held it leaves, or on a schedule. Rolling creates a new key and lets you keep the old one working for up to 7 days while you deploy the new one. Revoking ends the old key at once.

When you revoke a key because it leaked, every request with it stops at once. Seals record the ids of the keys that started their writing sessions, so you can find every seal it had a hand in.

Section titled “Related”