Verified from public page behavior on 2026-03-11.
- Navigating to
https://www.tossinvest.com/accountwithout an authenticated session redirected tohttps://www.tossinvest.com/signin?redirectUrl=%2Faccount. - The sign-in page exposed two visible entry modes:
- phone-based login
- QR-code login
- Public network activity on the sign-in page included
POST https://wts-api.tossinvest.com/api/v2/login/wts/toss/cert-init.
Captured from a real browser session on 2026-03-11 after QR login.
Observed login flow endpoints:
POST /api/v2/login/wts/toss/cert-initPOST /api/v2/login/wts/toss/qr- repeated
GET /api/v2/login/wts/toss/status POST /api/v2/login/wts/tossPOST /api/v3/login/ticket
Observed cookie names in browser storage state:
deviceIdbrowserSessionIdXSRF-TOKENSESSIONUTKLTKFTKBTK
Observed local storage keys:
WTS-DEVICE-IDqr-tabIdWTS-SYNC-SEEDlogin-methodDEVICE_INFO
Observed session storage keys:
WTS-BROWSER-TAB-ID
These observations suggest that both cookies and browser storage values matter for a durable WTS session. The auth helper should capture both, not cookies alone.
The CLI should not attempt to recreate the login flow in Go.
Instead:
- a Python auth helper opens a real browser
- the user completes login manually
- the helper extracts the minimum session state needed for subsequent read-only HTTP calls
- the Go CLI stores and reuses that state
- which subset of cookies are strictly required after successful login
- which subset of local storage or session storage values are strictly required
- whether request signing or CSRF tokens are needed for authenticated read endpoints
- whether session state differs between phone and QR flows
- whether the web app refreshes sessions silently
- do not store raw login captures in git
- do not commit cookies or personally identifying information
- do not implement trading-related flows in the auth helper