Reaching a Pocket Broker account through its live trading session

Open Pocket Broker on a funded account and the screen is driven by one long-lived WebSocket: balance, open positions, and a stream of candles and ticks all arrive over the same socket.io session. That session is the integration surface. Pocket Broker (com.potradeweb, per its Google Play listing) is a white-label client of the Pocket Option platform — the same backend, the same message format — so what holds for one holds for the other. Our job on this app is to turn that authenticated stream into something your code can call: a clean client, a written-down protocol, and tests.

The bottom line: the valuable records here are per-account and they move in real time, not in a nightly file. Because account state, trade history and live market data all ride the same authenticated socket.io session, we build the session client first and let the slower routes — a periodic cabinet export, a consenting-account read mirror — hang off that same client instead of duplicating it. Below is what is reachable, how, and what you get.

Authorized routes into a Pocket Broker session

Three routes apply to this app. They overlap deliberately — the same session client underpins all of them.

Protocol analysis of the live socket

We observe the socket.io traffic of an authorized account, document the frames, and rebuild the parts you need as a typed client. This is what reaches live ticks, candle subscriptions and balance changes. Effort is moderate; durability is good while the message schema holds, which is why we keep a schema check that flags a change after a platform update. Access is arranged with you during onboarding — the build runs against a consenting account or a practice balance, never an account you do not control.

User-consented session access

The platform already issues a session credential — the SSID string — to a logged-in browser. A consenting account holder hands that over, and a read-oriented mirror runs from it without ever storing a password. Light to stand up. It depends on a refresh routine, which we wire in, because sessions expire.

Native cabinet export

Trade history can be pulled from the web cabinet as a periodic file. It is the slowest and least granular path — closed trades only, no live stream — but it is a useful reconciliation backstop and we fold it into the same pipeline.

What the account session actually holds

These are the surfaces a Pocket Broker session exposes, named the way the app and its protocol expose them. Visibility of any one of them is set by the account's own permissions.

The handshake, in code

The shape below is illustrative and matches what we confirm during the build. The auth frame is the documented socket.io format — the SSID session is what gets passed, not a username and password.

# Pocket Broker / Pocket Option session client (illustrative)
import socketio, json

sio = socketio.Client()

SSID = load_consented_ssid()   # captured from a logged-in session at onboarding

@sio.on('connect')
def on_connect():
    # documented auth frame: 42["auth",{...}]
    sio.emit('auth', {
        "session": SSID,
        "isDemo": 0,            # 1 = practice balance, 0 = funded account
        "uid": ACCOUNT_UID,
        "platform": 1
    })

@sio.on('successauth')
def on_auth(_):
    sio.emit('subscribeMessage', {"asset": "EURUSD_otc", "period": 60})

@sio.on('updateBalance')
def on_balance(msg):
    store_balance(msg["balance"], demo=msg.get("isDemo"))

@sio.on('updateStream')        # candles / ticks
def on_tick(msg):
    write_ohlc(msg["asset"], msg["candles"])

# reconnect + region failover and an SSID refresh loop sit around this core
sio.connect(REGION_WSS, transports=["websocket"])

Field names are confirmed against the real traffic during the engagement; error handling covers a rejected or expired session, a region timeout, and a resubscribe after reconnect.

What lands in your repository

For Pocket Broker specifically, delivery is:

• A runnable session client (Python or Node.js) for the endpoints that matter to you — auth, balance, trade history, candle/tick subscription.
• An OpenAPI / Swagger description of the normalized HTTP surface we put in front of the socket, so your services call REST and we handle the WebSocket underneath.
• A protocol and auth-flow report: the socket.io frames, the SSID auth model, the isDemo switch, the reconnect and region-failover behaviour.
• Automated tests against a practice account, plus a small replay harness so recorded ticks can drive the suite without a live market.
• Interface documentation, and guidance on session-credential storage and data retention.

Authorization, the Comoros question, and data minimization

No open-banking or account-aggregation regime governs an offshore trading platform like this one, so the authorization that matters is the account holder's own consent to reach their session and their records. We work from that consent, in writing, scoped to the surfaces you actually need. Pocket Option is registered under the Mwali International Services Authority in the Comoros — a Tier-3 offshore regime that Traders Union and Finance Magnates both flag as contested, with the Comoros central bank having publicly disputed MISA-issued licences. That is not a reason the data cannot be reached; it is a reason to keep the integration consent-based, logged, and narrow. Where an account holder is in the EU, we treat their records under GDPR-style minimization — collect only the fields in scope, keep session credentials encrypted, and honour revocation by tearing the mirror down. NDAs cover the work when you need them.

Engineering notes we plan around

Three things about this platform shape the build, and we handle each:

• reCaptcha on the standard login. The normal credential login is gated by reCaptcha, so we anchor the integration on the session-string flow captured from a consenting account, and add a refresh routine so the connection does not silently expire mid-session.
• Multi-region sockets and keep-alive framing. The platform fans out across regional WebSocket endpoints with socket.io ping/pong keep-alives. We build reconnect and region failover so a dropped socket re-subscribes and the stream continues rather than going quiet.
• Demo and real share one protocol. The only thing separating a practice balance from a funded account in the auth frame is the isDemo flag. We parametrize that explicitly so the two feeds are tagged at the source and never co-mingle in your store.

Cost and how a build runs

A runnable Pocket Broker session client — with its OpenAPI spec, the protocol report, and tests — starts at $300 as source-code delivery, and you pay after it lands and you have checked it against your own account, not before. If you would rather not host anything, the second model is pay-per-call: we run the endpoints, you call them, and you are billed only for the calls, with no upfront fee. Either way the cycle is one to two weeks. Tell us the app and what you want out of it, and the access and compliance pieces get arranged with you as part of the work — start a brief on the contact page.

Where teams plug this in

• A trade journal that auto-imports closed positions from a real account instead of manual CSV entry.
• A risk dashboard that mirrors live balance and open exposure across several Pocket Broker accounts.
• A research store that records ticks and OHLC candles for a set of assets to backtest a strategy offline.
• A reconciliation job that matches cabinet funding events to an internal ledger on a schedule.

Interface evidence

Store screenshots of the surfaces an integration reads from. Select to enlarge.

How this mapping was put together

Checked in June 2026. We read the Google Play listing for the app's own feature claims, two independent reviews of the platform's Comoros registration and its contested status, and open-source community clients that document the socket.io auth frame and the surfaces it exposes. Primary sources, in new tabs:

• Pocket Broker on Google Play (com.potradeweb)
• Traders Union — Pocket Option regulation review (MISA / Comoros)
• Finance Magnates — the Comoros licence controversy
• Community Pocket Option WebSocket client documenting the auth frame

Compiled by the OpenBanking Studio integration desk, 26 June 2026.

Other platforms in the same category

The same session-and-stream pattern recurs across this category, which is why a single normalized client tends to extend cleanly to its neighbours. Neutral notes on what each holds:

• Quotex — binary options platform; per-account balances, trade history and live quotes behind a logged-in session.
• IQ Option — broader options, forex and CFD platform; CySEC-licensed, with account state and a market-data stream.
• Olymp Trade — fixed-time and forex trading; account ledger, positions and asset feeds per user.
• Binomo — beginner-oriented options app; demo and real balances, tournament records, trade logs.
• ExpertOption — multi-asset options app; per-account positions and live pricing.
• IQcent — options and forex broker; account balances and trade records behind login.
• Deriv — options, multipliers and CFDs; documented account and contract data per user.
• Exnova — options and forex platform; account state, trade history and streaming quotes.

App names are listed for context only — no ranking, no endorsement.

Questions integrators ask about Pocket Broker

Is Pocket Broker the same platform as Pocket Option?

Effectively yes. Pocket Broker (com.potradeweb) is a white-label client of the Pocket Option platform — the app's own listing routes support through Pocket Option, and both clients speak to the same trading backend. An integration built against the session protocol works the same way for either.

What authenticates a session, if not a key?

Access rides a session string the platform already issues to a logged-in browser — the SSID value carried in the socket.io auth frame. We capture it from a consenting account during onboarding and refresh it on a schedule so the connection does not lapse. No password is stored.

Can demo and live accounts be kept separate?

Yes. The auth frame carries an isDemo flag, so the client targets a practice balance or a funded account explicitly. We parametrize that so a demo feed and a real-money feed never get crossed in your data store.

Can the live tick stream be recorded for backtesting?

Yes. The candle and tick subscriptions can be written to a small replay harness so OHLC and sub-second prices are kept for research and reconciliation, rather than only consumed live.