No ORDER_STATUS_CHANGED events pushed despite access token NORMAL + SubscribeSuccess (US margin account)

[carlborrelli]

Summary

The gRPC trade-events subscription connects and stays healthy but never delivers order events, across many real orders, reproduced with the official SDK client.

Environment

• webull-openapi-python-sdk 2.0.14, Python 3.12, US region
• webull.trade.trade_events_client.TradeEventsClient → events-api.webull.com
• Access token created and 2FA-verified in the Webull app — status NORMAL
• HMAC-SHA256 signing (sha256-hex body), subscribeType=3
• Subscribed account ids taken from get_account_list() (all accounts, US margin included)

What we observe

• SubscribeSuccess on connect, continuous Ping keepalives for hours — stream is healthy
• Placed several REAL orders on the subscribed US margin account:
  • equity BUYs that FILLED (both regular and extended hours)
  • a limit SELL placed and then CANCELLED
• Every one of them is visible immediately via REST GET /trade/orders/list-today
• Zero EVENT_TYPE_ORDER / ORDER_STATUS_CHANGED messages were pushed — only Ping

Ruled out

• Our own code (identical behavior with the unmodified official SDK sample client)
• Legacy/wrong account ids (subscribed everything returned by get_account_list())
• Missing access token (created + 2FA-approved after reading OAuth access token support for gRPC trade events subscription? #8; status NORMAL)
• Half-open connection (keepalives flowing through the fill moments)
• Region/endpoint (US, events-api.webull.com resolves and accepts the subscribe)

Question

With token NORMAL, subscribeType=3, and SubscribeSuccess, what else enables the order-events push? Is there an app-level permission/scope or an account-to-app binding for trade events that must be enabled via the developer portal or support? Anything account-side (US margin) that gates it?

Happy to share app_key, account ids, and exact order timestamps privately for a server-side trace.

Cross-ref: #8 (comment)

[carlborrelli]

Additional verification: we cross-checked against the Java SDK (webull-openapi-java-sdk). TradeEventClient.subscribe builds the identical request — subscribeType=3 for US region, account ids via the proto's accounts field (field 5), signature call credentials — and the samples likewise pass plain account_id. So both official SDKs produce the same subscription we sent.

Also noting from events.proto: the server has explicit failure responses (AuthError, SubscribeExpired, NumOfConnExceed) and sent none — it acknowledged SubscribeSuccess and then delivered no order events for confirmed fills. This looks server-side: app-level push entitlement or account-class coverage. A server-side trace of our subscription would settle it — happy to provide identifiers privately.