The two ways in
A personal token or an assistant connection. Two ways to hold a bearer token, one door behind them.
Every call to the API carries a bearer token. There are two kinds, and which one you want depends on who is calling.
| Personal token | Assistant connection | |
|---|---|---|
| For | Your own scripts and tools | An assistant acting for a person |
| Made | Settings > Developers | OAuth, with a consent page |
| Belongs to | The person, every family or business they are in | One family or business |
| Scopes | As ticked, as the role allows | Read, or read and change |
| Plan | The paid plans | Every plan reads; change comes with the paid plans |
| Lives | Until revoked | A day, refreshed for ninety |
A personal token
Made in Settings > Developers, shown once, thaw_pat_…. It is yours rather than one family’s: the Thaw-Account header says which family or business a call is for, and without it the token opens the first one you belong to. The scopes are ticks on the form, and the form offers only what your role allows - a viewer’s token can read and ask but never change.
This is the way in for anything you write yourself: a script that files receipts from a folder, a shortcut, a dashboard, a backup. It comes with the paid plans.
An assistant connection
OAuth 2.1, the same flow the MCP server uses, with the person signing in and choosing on a consent page which family or business the assistant may see and whether it may change anything. The connection is bound to that one family or business, so it needs no Thaw-Account header.
The authorization server is Thaw itself at https://go.thawed.app; the two well-known documents say the rest:
curl https://api.thawed.app/.well-known/oauth-protected-resource
curl https://go.thawed.app/.well-known/oauth-authorization-server
A client registers by Client ID Metadata Document (the client id is an HTTPS URL to a JSON document naming its redirect_uris, client_name and logo_uri; Thaw fetches it and shows the name on the consent page), or by Dynamic Client Registration at POST /oauth/register as the fallback. PKCE with S256 is required, token_endpoint_auth_methods_supported is none, and the resource parameter chooses the door: https://api.thawed.app for the API, https://api.thawed.app/mcp for MCP. A token minted for one is refused at the other.
Scopes are thaw:read and thaw:write. On the API they become read and ask, and with thaw:write also write and identifiers. A connection never gets files: an assistant reads the words, not the PDF.
Access tokens live a day; refresh tokens ninety days, rotating on every use, and a reused refresh token ends the whole connection. POST /oauth/revoke takes either. The person can end a connection any time in Settings > AI assistants.
And Thaw’s own app
Thaw’s iPhone app comes through the same host with a token of its own, and a few of the things it does - signing in, drawing a page, the presses that only make sense in front of one - are its alone. Those paths are not in this reference, and they answer 404 to any other token, the same 404 an address nobody routed gets. Everything a person would want from their own paper is here.
Which one
Writing something for yourself: a personal token. Writing an assistant, an agent or a tool that acts for other people: an assistant connection, and read the MCP guide first, because most of what an assistant wants is already a tool there.