Registration and session creation

Call sequence

Observed from the Android client and successful local calls:

1. POST /registration/by_vk
2. POST /registration/get_session
3. POST /account/create_xtoken
4. GET /account/info_xtoken

Production host: https://vc.go.mail.ru.

Every request includes a client-generated device_id, device_ver, and client_request_id. Later authenticated calls also include session_id and, when available, Authorization: Bearer <session_secret>.

1. registration/by_vk

Parameters:

Name	Meaning
vk_access_token	VK OAuth access token from implicit flow
vk_user_id	Numeric VK user ID

A valid response has result.status = "READY" and result.token, the registration token used in the next step. This is not yet a Marusya session or a device xToken.

2. registration/get_session

Parameters:

Name	Value used
reg_token	result.token from by_vk
with_secret	1
with_account_info	1
accept_tos	1
accept_adv_mail	DEFAULT

The response supplies session_id, session_secret, and account_id. The session is the credential used for subsequent voice API calls. It is sensitive and must not be published.

3. account/create_xtoken

Parameters:

Name	Value used
timezone	e.g. Europe/Moscow
vk_subscribe_manual	1
wait_setup_wizard_finished	1
lat, lon	Optional device coordinates

Authentication uses the new session_id and Authorization: Bearer <session_secret>. The returned xtoken is the short-lived provisioning value encoded into configuration audio. account_id is optional in the audio JSON when the server does not supply it.

4. account/info_xtoken

A GET with xtoken_id and the Marusya session credentials returns:

• status
• device_online
• device_id
• serial

Observed status values from the client model: 1 = NEW, 2 = ERROR, 3 = CONNECTED, 4 = VK_ID_MISMATCH.

A successful setup has status = 3 and device_online = true. Merely associating with Wi-Fi does not prove provisioning: the API can still report NEW until the server accepts the audio payload.