Connection Flow

Step 1: Booking (GETCONF)

TLS connection to booking-loco.kakao.com:443.

Request:

{
  "GETCONF": {
    "os": "mac",
    "model": "mac"
  }
}

Response: Server configuration including checkin host list and port candidates.

Step 2: Checkin

Legacy encrypted connection (RSA handshake + AES-GCM) to a checkin server.

The client tries multiple host:port combinations from the booking response until one succeeds:

• ticket-loco.kakao.com:443 (TLS — may fail)
• ticket-loco.kakao.com:995 (Legacy encrypted)
• ticket-loco.kakao.com:10009 (Legacy encrypted)

Request:

{
  "CHECKIN": {
    "userId": 405979308,
    "os": "mac",
    "ntype": 0,
    "appVer": "3.7.0",
    "MCCMNC": "999",
    "lang": "ko",
    "countryISO": "KR",
    "useSub": true
  }
}

Response: Assigned LOCO server IP and port.

Step 3: Login (LOGINLIST)

Connect to the assigned LOCO server with RSA handshake + AES-GCM, then authenticate:

Request:

{
  "LOGINLIST": {
    "token": "<access_token>",
    "chatIds": [],
    "maxIds": [],
    "lastTokenId": 0,
    "lbk": 0,
    "bg": false,
    "os": "mac",
    "ntype": 0,
    "appVer": "3.7.0",
    "MCCMNC": "999",
    "lang": "ko",
    "dtype": 2,
    "duuid": "<device_uuid>",
    "prtVer": "1"
  }
}

When chatIds and maxIds are populated, the server returns recent messages for those chats in the response. This is used by the read command (v0.7.1+) to bootstrap message history directly from the login handshake, avoiding an extra SYNCMSG round-trip for the initial batch.

Response: Status 0 with userId, chat room list, and (when requested) per-chat chatDatas containing chatLog message arrays.

Auto-Refresh

If LOGINLIST returns -950 (token expired), the client automatically:

1. Calls login.json with X-VC header to get a fresh access_token
2. Retries LOGINLIST with the new token