Summary
PocketOptionAsync fails during client initialization with PocketOptionError, General error: Connection initialization timed out across multiple independent accounts and IPs simultaneously. Raw Socket.IO-level testing (bypassing the library) shows the server is reachable and the WebSocket/Engine.IO handshake completes normally, but the server explicitly responds to any auth payload with 42["NotAuthorized"] followed by 41 (Socket.IO DISCONNECT) — this is not a network timeout, it's an active rejection.
Environment
OS: Linux (Ubuntu 24.04, Docker containers)
Python: 3.11
Package: binaryoptionstoolsv2==0.2.11 (confirmed latest release, May 29 2026)
Import path: BinaryOptionsToolsV2.pocketoption.PocketOptionAsync
Timeline / Scope
Started: ~2026-07-19 14:00 UTC, ongoing for 4+ hours at time of writing
Affects 8+ independent long-running containers (some running continuously for 2-3 days prior without issue), using different SSIDs across different demo accounts
Also reproduced with a freshly created account, freshly generated SSID, different residential/proxy IP (not the same server as the long-running containers) — same failure
import asyncio
from BinaryOptionsToolsV2.pocketoption import PocketOptionAsync
async def main():
client = PocketOptionAsync(ssid='42["auth",{"session":"...","isDemo":1,"uid":...,"platform":2,...}]')
# Raises PocketOptionError: Connection initialization timed out
asyncio.run(main())
Raw protocol-level diagnostic (bypassing the library)
To isolate whether this was network-level or auth-level, we connected directly via the standard websockets Python library (bypassing binaryoptionstoolsv2 entirely):
wss://api-eu.po.market/socket.io/?EIO=4&transport=websocket
Result:
Raw WebSocket connects successfully (~0.1-0.15s)
Engine.IO handshake received normally: 0{"sid":"...","upgrades":[],"pingInterval":25000,"pingTimeout":20000,"maxPayload":1000000}
Sent Socket.IO CONNECT (40) → received normal 40{"sid":"..."}
Sent our auth payload (42["auth",{...}]) → server responds with:
451-["updateAssets",{"_placeholder":true,"num":0}] + binary asset list (generic public data, sent before auth is evaluated)
42["NotAuthorized"] ← explicit rejection
41 (DISCONNECT)
This sequence was identical with:
The original (multi-day-old) session SSID
A freshly generated SSID from a brand-new account on a different IP
With and without added Origin/User-Agent headers matching a real browser
Expected Result
Either successful authentication, or a specific, documented error distinguishing this from a generic timeout (the current PocketOptionError reported to the Python caller is a generic "Connection initialization timed out" — it does not surface the underlying NotAuthorized reason the server actually sends, which made this much harder to diagnose than necessary).
Additional Notes
This is not the previously-fixed May 2026 issue (#99) — we are already on 0.2.11, the version released specifically to fix that issue.
This is not the Windows tokio-panic issue (#98) — we are on Linux, and our processes do not crash; they cleanly catch PocketOptionError and log/retry as designed.
Tried alternate regional WebSocket URLs (api-eu, demo-api-eu, api-c) via the url= constructor parameter — api-eu was the only one that completed a raw handshake at all (others timed out or returned HTTP 403), but auth was still rejected there too.
Main website (https://pocketoption.com) responds normally and quickly (confirmed via curl), so this looks specific to the trading WebSocket backend's auth layer, not a general platform outage.
Would be happy to provide additional logs/packet captures if helpful.
Summary
PocketOptionAsync fails during client initialization with PocketOptionError, General error: Connection initialization timed out across multiple independent accounts and IPs simultaneously. Raw Socket.IO-level testing (bypassing the library) shows the server is reachable and the WebSocket/Engine.IO handshake completes normally, but the server explicitly responds to any auth payload with 42["NotAuthorized"] followed by 41 (Socket.IO DISCONNECT) — this is not a network timeout, it's an active rejection.
Environment
OS: Linux (Ubuntu 24.04, Docker containers)
Python: 3.11
Package: binaryoptionstoolsv2==0.2.11 (confirmed latest release, May 29 2026)
Import path: BinaryOptionsToolsV2.pocketoption.PocketOptionAsync
Timeline / Scope
Started: ~2026-07-19 14:00 UTC, ongoing for 4+ hours at time of writing
Affects 8+ independent long-running containers (some running continuously for 2-3 days prior without issue), using different SSIDs across different demo accounts
Also reproduced with a freshly created account, freshly generated SSID, different residential/proxy IP (not the same server as the long-running containers) — same failure
Raw protocol-level diagnostic (bypassing the library)
To isolate whether this was network-level or auth-level, we connected directly via the standard websockets Python library (bypassing binaryoptionstoolsv2 entirely):
wss://api-eu.po.market/socket.io/?EIO=4&transport=websocketResult:
Raw WebSocket connects successfully (~0.1-0.15s)
Engine.IO handshake received normally: 0{"sid":"...","upgrades":[],"pingInterval":25000,"pingTimeout":20000,"maxPayload":1000000}
Sent Socket.IO CONNECT (40) → received normal 40{"sid":"..."}
Sent our auth payload (42["auth",{...}]) → server responds with:
451-["updateAssets",{"_placeholder":true,"num":0}] + binary asset list (generic public data, sent before auth is evaluated)
42["NotAuthorized"] ← explicit rejection
41 (DISCONNECT)
This sequence was identical with:
The original (multi-day-old) session SSID
A freshly generated SSID from a brand-new account on a different IP
With and without added Origin/User-Agent headers matching a real browser
Expected Result
Either successful authentication, or a specific, documented error distinguishing this from a generic timeout (the current PocketOptionError reported to the Python caller is a generic "Connection initialization timed out" — it does not surface the underlying NotAuthorized reason the server actually sends, which made this much harder to diagnose than necessary).
Additional Notes
This is not the previously-fixed May 2026 issue (#99) — we are already on 0.2.11, the version released specifically to fix that issue.
This is not the Windows tokio-panic issue (#98) — we are on Linux, and our processes do not crash; they cleanly catch PocketOptionError and log/retry as designed.
Tried alternate regional WebSocket URLs (api-eu, demo-api-eu, api-c) via the url= constructor parameter — api-eu was the only one that completed a raw handshake at all (others timed out or returned HTTP 403), but auth was still rejected there too.
Main website (https://pocketoption.com) responds normally and quickly (confirmed via curl), so this looks specific to the trading WebSocket backend's auth layer, not a general platform outage.
Would be happy to provide additional logs/packet captures if helpful.