Getting structured data out of IQ Option’s trading stack

IQ Option’s mobile app keeps almost nothing useful on the device. Balances, open positions, closed-trade results, payouts and live candle data all sit behind an authenticated session: the client logs in over HTTPS, the server hands back a session identifier, and from that point a single WebSocket carries the real-time traffic. That shape is the whole reason an integration is worth doing — and the reason a thin screen-scrape is the wrong tool. The data is structured and pushed, not rendered into a page.

So the route we take is direct. We watch one consenting account’s real traffic, document the login-to-socket handshake and the message frames behind each surface you care about, then rebuild those calls as a clean library. The lead surface for most clients is the closed-position history plus the live balance feed; the candle streams come along for charting and backfill. Below is what is reachable, how the session actually behaves, and what we hand over.

What the account holds, and where it lives

Ways into the data, and the one we pick

Three routes genuinely apply to this platform. None of them requires anything from you up front beyond the account name and what you want out of it — access is arranged with you as part of the work.

Authorized protocol analysis of the app session

The primary path. We capture the real HTTP-login and WebSocket traffic from a consenting account, map the SSID handshake and the frame schema for balances, positions, history and candles, and reimplement those calls. Reachable: every surface in the table above. Effort: a few days to map, the rest of the cycle to harden. Durability: good, with one caveat handled in the build notes — the frame format can shift when the platform updates, so we wire change-detection in rather than assume it stays put.

User-consented session access

Where you only need read access for a known account, we run the integration against that account’s own authenticated session, scoped to the surfaces you asked for. Cleanest consent story, and it sidesteps credential storage when a short-lived session token is enough. We set up the consent capture and rotation with you during onboarding.

Native export as a fallback

The web and desktop platform can produce trade statements an account holder can download. Useful as a reconciliation check or a cold-start backfill, but it is manual and lagging, so we treat it as a cross-check against the live integration rather than the feed itself.

For almost every brief here the protocol-analysis route is the one we build and run, with user-consented session access layered on top for the consent record; native export stays a verification step. That ordering is driven by the data being pushed over the socket in real time — a statement download cannot give you live positions or streaming candles.

How the session actually behaves

The handshake below reflects how the login-to-socket flow works on this platform; field names are confirmed against a real session during the build, and the snippet is illustrative of the shape, not a copy of production code.

# 1) HTTP login -> session identifier (SSID) returned in the auth response
POST https://auth.iqoption.com/api/v2/login
  body: { identifier, password }
  -> 200; Set-Cookie: ssid=<session-id>

# 2) Open the WebSocket the app uses and authenticate the socket with the SSID
WS  wss://<trade-host>/echo/websocket
  -> send { "name": "ssid", "msg": "<session-id>" }
  -> server confirms; session is now live on the socket

# 3) Ask for the surfaces you need on the same socket
  -> send { "name": "get-balances",  "request_id": "r1" }
  -> send { "name": "subscribe",     "msg": { "name": "candle-generated",
                                              "params": { "active_id": 1, "size": 60 } } }
  -> send { "name": "portfolio.get-history-positions",
            "msg": { "instrument_types": ["digital-option","cfd"], "limit": 100 } }

# Response framing (normalized on our side)
{ "name": "balances", "msg": [ { "id": 0, "type": "real",     "currency": "USD", "amount": 0.0 },
                               { "id": 0, "type": "practice", "currency": "USD", "amount": 10000.0 } ] }

# Error handling we build in:
#  - SSID expired      -> re-run step 1, re-auth the socket, resume subscriptions
#  - socket dropped    -> reconnect with backoff, replay active subscriptions
#  - frame schema drift -> validator flags unknown fields instead of failing silently
      

What lands in your repo

Each deliverable is tied to the surfaces above, not a generic checklist:

• An OpenAPI / asyncapi-style spec covering the HTTP login and the WebSocket frames for balances, positions, history, candles and payouts.
• A protocol and auth-flow report: the SSID login chain, socket authentication, subscription lifecycle and re-auth path, written down so a second engineer can maintain it.
• Runnable source for the key surfaces in Python or Node.js — login, socket auth, balance read, history pull, candle subscribe and backfill — with reconnect and re-auth handled.
• Automated tests against recorded frames so a schema change breaks a test, not production.
• A normalized schema that flattens digital, turbo and CFD trade results into one history record.
• Interface documentation plus data-retention and consent-logging guidance.

Consent and who oversees the entity

IQ Option splits by region: international clients are served by SKY LADDER LLC, registered in Antigua and Barbuda (Registration No. ILLC 004, per the app’s own listing), while EU clients sit under a Cyprus entity holding CySEC licence 247/14 (per IQ Option’s regulation page). There is no open-banking or account-aggregation regime that covers a CFD broker here, so the dependable basis for the integration is the account holder’s own authorization — not a statutory data-sharing scheme.

That shapes how we run it. We work from a consenting account and a session it owns; we keep consent and access records; we scope retention to the surfaces the project needs and drop the rest; and we sign an NDA where the engagement calls for one. For EU accounts under the Cyprus entity, personal fields are handled under GDPR — minimized, and not retained beyond the agreed purpose. Consent can be revoked by ending the session, and the integration is built to fail closed when it is.

Build notes specific to this platform

Two things about IQ Option drive design decisions, and we handle both rather than push them back to you:

• Frame schema can move under the platform. Because the data rides a private WebSocket protocol, a platform update can rename or reshape a frame. We build a validator that flags unknown or missing fields and a small recorded-frame test suite, so a change surfaces as a failed check during maintenance instead of corrupt data downstream.
• Sessions expire and sockets drop. The SSID is not permanent and the socket can close mid-stream. We design the client to detect an expired session, re-run the login, re-authenticate the socket and replay active subscriptions automatically, so a multi-day balance-and-candle feed does not quietly go stale.
• Three instrument families, one history. Digital options, turbo options and CFDs report results differently. We map all three into a single normalized trade record so reporting code does not branch per instrument type.

Latency and data freshness

Balances and positions update on the socket as the account changes; the candle subscribe channel pushes new bars on close, so the feed is effectively real-time once the session is live. History is a request, not a stream — we page it on a schedule and on demand. The native statement download lags by design and is used only to reconcile, never as the live source.

Interface evidence

Public store screenshots of the surfaces the integration maps — trade room, asset lists and account views. Select to enlarge.

Comparable platforms a unified feed would cover

Teams integrating IQ Option usually want the same shape of data from neighbouring platforms. Named here for ecosystem context only:

• Pocket Option — binary and short-term trading with 100+ assets; balances, trades and payouts behind a similar authenticated session.
• Binomo — binary-focused platform with tiered accounts; holds per-user trade history and balances.
• Quotex — digital options with built-in analytics; account, trade and signal data behind login.
• Olymp Trade — options and CFDs; positions, history and demo/real balances per account.
• Deriv — multi-asset broker (options, forex, CFDs) with a documented account model and per-user records.
• Nadex — a US exchange model rather than a broker; holds order and contract records per member.
• ExpertOption — fixed-time trades with a mobile-first app; balances and trade logs behind an account.
• OANDA — forex and CFD broker; account balances, transaction history and pricing data per client.

How this was checked, and against what

I read the app’s Play Store description for the asset mix, account model and operator entity, then confirmed the regulatory split and the session mechanics against the sources below. The protocol behaviour was cross-checked against community documentation of the platform’s WebSocket interface; frame names are verified against a live session at build time, not asserted from those docs. Checked June 2026.

• IQ Option — Licenses and safeguards (CySEC 247/14)
• Google Play listing — com.iqoption
• Community protocol documentation — WebSocket channels and SSID auth
• BrokerChooser — IQ Option entity and regulatory overview

Mapped by the OpenBanking Studio integration desk · June 2026.

Questions an integrator tends to ask

Does the integration cover both the practice and real balances IQ Option shows in the app?

Yes. After the session authenticates, the platform reports each balance the account holds — the reloadable practice balance and any funded real balance — with its currency and type, so the feed can mirror exactly what the in-app account switcher shows.

How do you reach IQ Option’s candle and quote streams without hammering the server with polling?

The platform pushes OHLC and quote data over a subscription channel on the same WebSocket the app uses. We subscribe per instrument and timeframe and read the stream as it arrives, with a separate request path for historical candle backfill, rather than re-polling an HTTP endpoint.

IQ Option runs under SKY LADDER LLC in Antigua and under CySEC in the EU — does that split change the consent model?

The legal entity differs by region, but the integration is built on the account holder’s own authorization either way: we work from a consenting account and a session it owns, keep consent and access records, and scope retention to the data the project needs. For EU accounts under CySEC that also means handling personal data under GDPR.

Can you deliver just the trade-history endpoint as runnable source instead of a hosted feed?

Yes. A single surface — closed positions and option results normalized into one history schema — can be delivered as standalone Python or Node source with tests and docs, independent of the balance and candle surfaces, if that is all you need.

Pick how you take delivery. One model is source-code delivery from $300 — the runnable client, spec, tests and docs land in your repo, and you pay after delivery once the surfaces check out. The other is a hosted endpoint you call and pay per call, with no upfront fee. Either way the cycle is one to two weeks; tell us the account and which surfaces you need and we will start the integration.