Skip to main content
Every request to the Open API — public data included — requires a personal API key (PAT). Keys are bound to a SeeSaw user account: public tools see the world, *_my_* tools see that account, and write operations act as that account.

​
Using your key

Send it as a standard bearer token on both faces:
There is no OAuth flow and no token exchange: the key itself is the credential on every request.

​
Scopes

A key’s permissions are fixed when you create it. There are two tiers:
Scopes cannot be changed after creation. There is no upgrade path: to move from read to read+write, create a new key and revoke the old one. This is deliberate — a key’s authority never silently grows.
Notes:
  • Both tiers include read. There is no write-only key — a key that could act but not see what it was acting on would be worse, not safer.
  • The prefix is the same (sspat_) for both tiers. You cannot tell a key’s authority by looking at it; check the scopes field in the app.
  • A read-only key calling a write endpoint gets 403 FORBIDDEN_SCOPE. Over MCP the write tools are simply absent from its tool list.
  • Keys created for you by the SeeSaw team are always read-only. A write key must be created by the account owner.
Default to read. Only create a write key for an agent you actually intend to let spend coins, and prefer a separate key for it so you can revoke that capability without disturbing your read integrations.

​
Key facts

​
Getting and managing keys

Create and revoke keys yourself in the SeeSaw app, under the MCP section of the sidebar. You choose the scope tier when creating the key, and the raw key is shown once — copy it then. Key management lives on the app API (JWT-authenticated, /v1/users/me/api-keys) — it is deliberately not part of the Open API surface, so a leaked key cannot mint or revoke keys, whatever its scopes.

​
Security notes

  • Treat keys like passwords. Any key can read your balance and positions; a write key can spend your coins. Don’t paste keys into shared prompts, logs, or screenshots.
  • Don’t commit keys to git. The sspat_ prefix is designed to be secret-scanner friendly; treat any committed key as leaked.
  • Leaked? Revoke it immediately and create a fresh one. Revocation propagates in about a minute. A leaked write key is urgent — revoke first, then check list_my_coin_ledger for movements you didn’t authorize.
  • Prefer one key per client/integration so you can revoke narrowly.

​
What’s next

OAuth 2.1 is planned for a later phase — it unlocks clients where you can’t set custom headers (claude.ai web connectors, ChatGPT connectors). API keys will keep working unchanged.