Кто-нибудь разбирался с API Pocket Option для своих небольших скриптов?

Пытаюсь понять, как сейчас вообще правильно подходить к pocket option api. Хочу не торгового робота собирать, а просто получать котировки и сохранять их у себя для последующего анализа. На форумах попадаются примеры на Python, но там часто непонятно, это рабочий способ или старый кусок кода, который держится на неофициальном подключении.

Особенно запутал момент с авторизацией и потоком данных: где-то пишут про веб-сокеты, где-то используют автоматизацию браузера. На демо проверять вроде удобнее, но не хочется сразу строить всё на хрупком решении. Кто уже подключал pocket option api или делал похожий сбор данных? Подскажите, с чего лучше начать и какие подводные камни вы встретили вначале?

Для сбора котировок я бы начал с демо и отдельного клиента WebSocket, без автоматизации браузера. У Pocket Option интерфейс меняется, неофициальная авторизация ломается внезапно, поэтому сохраняйте сырые сообщения и закладывайте переподключение.

DarkFox84 написал:
Для сбора котировок я бы начал с демо и отдельного клиента WebSocket, без автоматизации браузера. У Pocket Option интерфейс меняется, неофициальная авторизация ломается внезапно, поэтому сохраняйте сырые сообщения и закладывайте переподключение.

Хороший совет про сырые сообщения: я бы ещё сразу добавил метку времени получения и версию формата в лог. Тогда после очередного изменения WebSocket будет проще понять, где сломался парсер, а не терять весь архив.

С версией формата хорошая мысль. Я бы ещё сохранял идентификатор инструмента и локальное время отдельно от времени события: при задержках WebSocket это сильно помогает не перепутать порядок котировок.

DarkFox84 написал:
Для сбора котировок я бы начал с демо и отдельного клиента WebSocket, без автоматизации браузера. У Pocket Option интерфейс меняется, неофициальная авторизация ломается внезапно, поэтому сохраняйте сырые сообщения и закладывайте переподключение.

Именно, без этого потом в логах каша. Я в похожем сборе сразу вынес id инструмента и свой timestamp — после пары разрывов WebSocket это реально спасло, иначе парсер молча врал.

Свой timestamp — это база, но я бы ещё писал причину разрыва: код закрытия сокета и номер попытки. Иначе потом не отличишь, где данные пропали из-за реконнекта, а где платформа реально молчала.

Код закрытия — вещь, но номер попытки мало что даёт. Я вместо него пишу timestamp разрыва и момент первого сообщения после реконнекта: сразу видно, сколько котировок реально потеряно, а не гадать.