Автоматизация на Pocket Option: реально ли прикрутить своего бота?

Давно хотел попробовать автоматизировать торговлю, а то руками постоянно косячу из-за эмоций, и вот решил покопаться в том, как вообще работает pocket option сайт с точки зрения софта. Вроде как напрямую API не дают, или я просто где-то пропустил этот момент в настройках профиля. Сейчас смотрю разные варианты с кликерами или какими-то внешними скриптами, но это выглядит как какой-то костыль, который может в любой момент отвалиться или вообще привести к тому, что аккаунт забанят за сторонний софт. Блин, очень хочется найти что-то более стабильное, чтобы бот просто по стратегии заходил, а я только контролировал процесс. Кто-нибудь из вас пробовал писать своих роботов именно под эту платформу или пользовался готовыми решениями? Интересно, насколько это вообще безопасно сейчас и есть ли смысл тратить время на разработку своего алгоритма, или проще искать провереный софт, который уже работает. Может, есть какие-то обходные пути, о которых мало кто знает? Поделитесь опытом, кто реально запус

Забудь про поиск API в настройках, его там нет и не будет. Платформа просто не дает официального доступа для своих ботов. Кто-то пытается через эмуляцию кликов или перехват запросов, но это прямой путь к бану аккаунта, как только система заметит подозрительную активность. Если не хочешь слить депозит из-за глюка софта или блокировки, лучше оставить ручную торговлю, просто дисциплину подтянуть. Автоматизация тут — это всегда игра в кошки-мышки с админами.

Видишь, я тоже уже несколько недель копался в «черных» методах, и могу подтвердить, что без официального API всё равно придётся идти по скользкой дороге, где каждый клик, каждый запрос может стать мишенью для анти‑ботов. На моих тестах эмуляция мыши через Selenium работала минут пять, потом система начала отвечать капчей, а через пару часов аккаунт получил «необычную активность» и блокировку. Перехват веб‑сокетов вроде бы выглядит более «чистым», но в реальности сервер всё равно проверяет токен‑пользователя и подпись запросов, а эти параметры формируются в закрытом JS‑файле, который меняется каждый выпуск. Я попробовал собрать их вручную, но через 24 часа кода всё равно начал падать из‑за нового хеша. Поэтому, если цель – стабильный доход без риска «съесть» депозит, проще взять готовый сервис, который имеет договорённости с брокером, либо переключиться на платформу с открытым API. Если же всё‑равно решишь идти по пути «хака», готовься к постоянным правкам кода, мониторингу ответов и, главное, к тому, что любой очередной бан может стоить гораздо больше, чем потенциальный выигрыш. Так что мой совет: либо откажись от собственного бота, либо закладывай в план резервный фонд для возможных потерь и держи руку на пульсе обновлений сайта.

Сейчас в теме, что без официального API Pocket Option ‑ это уже почти квест в стиле «выживание». У меня тоже был эксперимент: вместо Selenium пробовал «надстроить» запросы через DevTools, подменяя токен session и подписывая хэши вручную. Первые три‑четыре сделки прошли без проблем, но уже на пятой платформа начала бросать 403 – как будто у неё включён «интеллектуальный» мониторинг частоты одинаковых payload. Плюс, каждый раз, когда менял гео‑IP, сразу получал капчу, которую нельзя пройти скриптом без сторонних сервисов. Вывод: в реальном времени поддерживать «чёрного» бота без постоянного обновления подписи и прокси‑пула почти невозможно. Если всё‑таки решитесь пускать код, готовьте скрипт‑хакер, который будет случайным образом менять заголовки, паузы и даже имитировать небольшие «ошибки» мыши, иначе система быстро распознает вас как шаблон. И помните, что любой такой подход нарушает условия сервиса – так что рискуете не только блокировкой, но и потерей средств.

Тут я врезаюсь в тот же барьер, что и EgorSlate – без «чистого» API Pocket Option приходится играть в шахматы с их клиентской частью. Я пробовал подход, похожий на твой, но взялся за перехват WebSocket‑сообщений в DevTools, а не просто за HTTP‑запросы. Сначала всё выглядело обещающе: после подмены токена session удалось отправить две‑три ордера, но уже на четвёртой попытке сервер выкинул ошибку 401 – похоже, они динамически подпишут хэш‑ключ к каждому запросу, используя в‑рамках JS‑функцию, которую я не смог «склонировать» без полного контекста. После этого я откатился к Selenium, но уже не как к основной движке, а лишь к симуляции пользовательского ввода, чтобы «размять» токен session перед каждой новой сессией. Вывод для меня таков: без официального API любой «надстрой» будет работать лишь пока не поменяют подпись или не внесут небольшие правки в клиентскую логику. Поэтому либо готовить собственный «костыльный» шлюз, который будет каждый раз заново получать свежий токен через скрипт‑инъекцию, либо смириться с тем, что стабильной автоматизации пока не придумать.

Сейчас пробую то же, что и ты, но отталкиваюсь от того, что после подмены токена в WS‑сообщениях сразу падает heartbeat – сервер считает соединение «неавторизованным». Я отловил, что токен формируется в функции signRequest() внутри bundle.js и подпадает под SHA‑256 с солью, меняемой каждые 30 сек. Поэтому простая подмена в DevTools работает лишь несколько запросов, а дальше всё отваливается. Решение – «перехватить‑перегенерировать» подпись в реальном времени: подключить к странице пользовательский скрипт (Tampermonkey), который каждый раз пересчитывает хеш и подсовывает его в outbound‑сообщение. Плюс‑минус, но без этой «живой» подписи бот будет работать только в «песочнице», а реальная торговля всё равно останется под угрозой блокировки.

Соль каждые 30 секунд — это уже не просто обфускация, а полноценная защита от реплея. Если ты подменяешь токен вручную, но не эмулируешь генерацию signRequest с актуальной солью, сервер убьёт коннект по heartbeat за пару циклов. Пробовал копать в сторону извлечения логики в headless-характере? Там хотя бы контекст JS сохранён.

Ну ты загнул про headless. Пробовал запускать через puppeteer, но там задержки такие, что никакой профит не вывезет. Если реально пытаться вытянуть алгоритм генерации этой соли из JS-бандла, то можно просто время жизни процесса просрать, пока дебажишь. Тут проблема не в headless, а в том, что Pocket Option реально жестко завязали проверку на консистентность сессии. Если хоть один параметр в signRequest не совпадает с тем, что ожидает сервер после heartbeat, всё — бан по коннекту. По сути, без полноценного реверса их логики шифрования это просто пустая трата времени.

Да в Puppeteer дело даже не в задержках, а в том, что они палят эмуляцию моментально. Если пытаться лезть в соль через дебаг, то на Pocket Option можно только слив депозита ускорить, пока возишься с JS.

У меня тоже эмуляция в Puppeteer ломается мгновенно, как только пытаешься менять signRequest. Ловить соль в devtools — бессмысленно, бот падает, а депозит уже исчезает.

Путешествие в signRequest — это прямой путь в бан. Pocket Option давно не просто соль ищет, там фингерпринт.canvas/webgl/audio контекст собирают ворклетом еще до логина. Puppeteer с его дефолтным профилем светится как фара в ночи. Пробовал патчить через CDP — ловили за 3-4 запроса. Единственное, что дало живучесть — настоящий хром в headed режиме с профилем, где куки/локелстораджи накапливались неделями. И даже так — рандомные чекпоинты на вводе кода из смс убивают всё. Депозт сливается не от задержек, а от того, что их антифрод видит «чистый» браузер без истории. Парни, которые реально вывозят — не эмулируют, а арендуют фермы устройств с аппрувленными аккаунтами. Дешевле не выйдет.

Проблема не в signRequest, а в том, что контекст воркера уже «грязный» до запуска твоего кода. Плейрайт со стелсом пробовал — тоже ловит на энтропии внутри скоупа воркера.

Ворклеты как раз и запускаются до основного потока, поэтому контекст воркера «грязится» первым. Плейрайт тут бессилен — он управляет страницей, а не изолированным JS-скопом. Нужно либо патчить сам воркер на уровне Service Worker interception, либо отказаться от браузерной автоматизации в пользу чистого API с эмуляцией всего фингерпринта (canvas noise, webgl vendor, audio context) на стороне клиента. Второй путь сложнее в старте, но банов не даёт.