Docs/API

win.sh API reference

The first public API surface is focused on local agent harnesses: browser-approved API tokens, bearer auth, and connector snapshots for loops.

Authentication

Send API tokens with standard bearer auth. Tokens start with win_live_ and are shown only once when created.

Authorization: Bearer win_live_...

CLI approval flow

The local CLI starts a localhost callback, opens win.sh, and waits for the browser approval redirect.

win auth login
GET /settings/api-tokens/cli?client=win-loops
  &redirect_uri=http://127.0.0.1:49152/callback
  &state=<random-state>

After approval, win.sh redirects to the callback with token, state, workspace, api_url, and expires_at.

Token endpoints

GET/api/settings/api-tokens

List the current user's tokens. Revoked tokens are included for auditability.

POST/api/settings/api-tokens

Create a token. The raw token is returned once in the response body.

{
  "name": "Local CLI",
  "source": "settings",
  "scopes": ["loops:read", "loops:run", "snapshots:read"],
  "expiresInDays": 90
}
DELETE/api/settings/api-tokens/{id}

Revoke a token owned by the current user.

Connector snapshots

Local loops can request a hosted connector snapshot before handing work to an agent.

GET/v1/loops/{loop}/connector-snapshot

Return the latest connector snapshot available for a loop and workspace.

curl https://win.sh/v1/loops/bug-autofix/connector-snapshot \
  -H "Authorization: Bearer win_live_..."

The current response shape is intentionally small: loopId, generatedAt, workspace, connectors, and signals.

Security notes

  • Only token hashes are stored server-side.
  • Existing tokens can be revoked, but raw token values cannot be retrieved.
  • The CLI approval route only accepts local HTTP callbacks.
  • Use short-lived, scoped tokens for local harnesses and CI.