Getting at the order and position records inside Webull Thailand

Webull Securities (Thailand) reported more than 300,000 registered users by early 2025, per a PR Newswire release tied to its Thai launch — every one of those accounts sits on top of structured server-side records: open positions, a full order book across four equity markets, cash by currency, and the funding transfers that move money into the broker entity. That is the data a portfolio tracker, an accountant, or a treasury dashboard wants out of the app, and none of it lives on the phone in a form you can simply read off.

The app names these surfaces the way any broker does — a positions screen, an orders list with fills and timestamps, an asset summary, a deposit/withdrawal history. We reach them by analysing the authenticated session the app itself uses, under the account holder's consent, and hand back source code that pulls the same records on demand. For a Webull Thailand account the order history is the centre of gravity, because it spans US, SET, Hong Kong and China trades that an integrator otherwise has to stitch together by hand.

What the account actually holds

Routes to the data

Thailand has no consumer open-finance scheme covering securities accounts the way some markets cover bank accounts, so an investor's broker data is reached through the account itself rather than a regulator-mandated consent rail. Three approaches genuinely apply here.

Protocol analysis of the authenticated app

The app authenticates a session and then exchanges structured payloads for positions, orders and balances. We capture that traffic against a consenting account, map the request and response shapes, and reproduce the login, token-refresh and query sequence in code. This is the approach that reaches the full order book across all four markets, and it is the one we would build the integration on. Effort is moderate; durability depends on how often the app's front end changes, which we account for in maintenance.

User-consented credential access

Where an account holder authorizes it, the integration runs as that user — the same session the app would establish, scoped and logged. This suits a single-account or a managed-accounts setup and pairs naturally with the protocol work above.

Native statement export

Statements and confirmations the app already produces are a low-effort fallback for periodic, document-grade records. They lag live state and are coarser than the order feed, so they back up the integration rather than carry it.

A sketch of the capture

Illustrative only — field names and the exact auth chain are confirmed during the build against a live, consenting account, not asserted here.

# Session bootstrap, then a positions pull. Shapes verified during the build.
POST /account/session/refresh
  headers: { device-id, app-ver, access-token }
  body:    { refresh_token }
  -> 200   { access_token, expires_in, account_id }

GET /trade/positions?accountId={account_id}&assetType=ALL
  headers: { access-token }
  -> 200 {
       "positions": [
         { "symbol": "AAPL",  "market": "US",  "qty": 12,
           "avgCost": "188.40", "mktValue": "2410.80", "ccy": "USD" },
         { "symbol": "PTT",    "market": "SET", "qty": 500,
           "avgCost": "34.25",  "mktValue": "17500.00", "ccy": "THB" }
       ]
     }

# normalize on read: one schema across US / SET / HK / CN
def to_holding(row):
    return {
      "symbol":   row["symbol"],
      "venue":    row["market"],          # US | SET | HK | CN
      "quantity": float(row["qty"]),
      "value":    {"amount": row["mktValue"], "currency": row["ccy"]},
    }

# on 401, refresh once and replay; on repeated 401, re-consent.
      

What you get back

The deliverable is a working integration, not a report. For a Webull Thailand build that means:

• An OpenAPI/Swagger spec describing the endpoints we reproduce — positions, orders, balances, funding, statements.
• A protocol and auth-flow report covering the login, token-refresh and session chain as it behaves on this app.
• Runnable source for the key calls in Python or Node.js, including the cross-market normalization shown above.
• Automated tests that exercise the auth path and the order/position pulls against recorded fixtures.
• Interface documentation plus a data-retention and consent-revocation note keyed to PDPA.

Consent and PDPA

Two things govern this work in Thailand. The broker, Webull Securities (Thailand), is licensed under the Thai SEC; the personal data inside the account falls under the Personal Data Protection Act (B.E. 2562), enforced through the PDPC. In practice that means the lawful basis we rely on is the account holder's own consent, recorded and revocable. We log what was accessed and when, touch only the fields a given use case needs — a tax export does not need watchlists — and sign an NDA where the engagement calls for it. Consent scope, expiry and a withdrawal path are written into the handover so the integration can be switched off cleanly.

Build notes specific to this app

Two details shape how we put a Webull Thailand integration together.

• Four markets, four conventions. US, SET, Hong Kong and China trades carry different symbology, trading hours and settlement rules. We normalize symbols, currencies and timestamps into one schema during capture, so a US fill and a SET fill land on the same ledger instead of in four incompatible exports.
• 24-hour sessions and a live quote channel. The app promotes round-the-clock US trading and real-time quotes, which arrive on a push channel, not a poll. We separate the streaming quote capture from the scheduled position and balance sync, and time the sync around the overnight session so a snapshot taken mid-session is not silently stale.
• Funding through a named entity. Money moves via the account titled "Webull Securities (Thailand) Co., Ltd.", as the app states. We map the transfer and settlement states so funding reconciliation matches the broker's own status model.
• Front-end drift. Broker apps reshape screens often. When the app's front end shifts, we re-run the capture and diff the endpoints as part of ongoing maintenance, so the integration tracks the change instead of breaking on it.

Access to a consenting account or a sandbox is arranged with you during onboarding — it is part of the project, not something to clear before we begin.

Pricing

Source-code delivery for a Webull Thailand integration starts at $300, and you pay it only after the working code is in your hands and you are satisfied with it. The alternative is the hosted route: call our endpoints for positions, orders and balances and pay per call, with nothing upfront. Either way the build runs on a one-to-two-week cycle. Tell us the app and what you need from its data, and we take it from there — start at /contact.html.

Where this gets used

• A multi-broker portfolio app that needs Webull Thailand holdings sitting next to local SET positions in one view.
• An accounting workflow that pulls the cross-market order history each quarter for capital-gains reporting.
• A treasury dashboard reconciling THB and USD cash and the funding transfers into the broker account.
• A research tool feeding off the same watchlist symbols a user already tracks in the app.

Screens we worked from

Nearby apps in the same space

Thai investors usually hold accounts across several of these, which is why a unified integration is worth building. Named for context, not ranked.

• InnovestX — local equities, mutual funds and digital assets in one app; holds positions and order records much like Webull's.
• Dime — fractional US shares and savings features; per-user holdings and cash worth aggregating.
• Streaming (Kasikorn Securities) — the long-standing SET trading front end; order book and portfolio data for Thai equities.
• Liberator — no-fee Thai stock app; account positions and trade history behind login.
• Bualuang Securities — bank-affiliated broker with SET trading and statement archives.
• Interactive Brokers — global multi-asset accounts; deep position and order data across many venues.
• Saxo — global trading platform with multi-currency cash and instrument coverage.
• SCB (SCBS / InnovestX legacy) — bank-broker equity accounts with order and balance records.

Questions integrators ask

Can US, Thai, HK and China trades come out as one normalized order feed?

Yes. The app holds orders across all four markets, each with its own symbology, trading calendar and settlement convention. We normalize symbols, currencies and timestamps to a single schema so a US fill and a SET fill reconcile against one ledger.

How is the real-time, 24-hour quote stream handled versus end-of-day snapshots?

Webull Thailand advertises 24-hour US trading and live quotes, which arrive over a push channel rather than a simple poll. We capture the streaming channel separately from the periodic position and balance sync, so quotes stay live while account state is pulled on a schedule that suits the overnight session.

Which regulator and privacy law shape a Webull Thailand integration?

Webull Securities (Thailand) operates under the Thai SEC, and personal data is governed by Thailand's Personal Data Protection Act (PDPA, B.E. 2562). We work from the account holder's consent, log access, and minimize the data fields we touch to what the use case needs.

How do you reach the account without raw credentials being spread around?

Access is arranged with you during onboarding against a consenting account. We hold session and token material in a scoped, logged store, pull only the fields the integration needs, and document a retention and revocation path so consent can be withdrawn.

Sources and who checked this

Checked in June 2026 against the app's Play Store listing, the operator's launch announcement, and Thai data-protection guidance. Primary sources opened: Google Play listing (org.dayup.stocks.th), PR Newswire — Webull Thailand launch, Stock Exchange of Thailand privacy notice, and PwC on Thailand's PDPA.

Mapped by the OpenBanking Studio integration desk, June 2026.