A live trading dashboard has two separate connections to design: how your backend gets account information, and how an authorized viewer receives updates. Choosing WebSocket for the browser connection does not require the upstream MT5 provider to offer a WebSocket API. Conversely, a streaming upstream feed does not eliminate the need for account snapshots and recovery.
This guide compares the roles of REST, webhooks and client streaming, then describes an application architecture around MetaKit's actual public interface. It does not introduce a new hosted streaming endpoint or promise tick-by-tick delivery. The distinction matters when evaluating an MT5 WebSocket API search result against a product's documented capabilities.
Three mechanisms, different responsibilities
REST-style HTTP reads retrieve a resource representation on request. HTTP semantics are defined in RFC 9110. A request for positions can supply a useful current view, but one successful response is not a subscription to later changes.
WebSocket establishes a connection for bidirectional message exchange, as defined by RFC 6455. The application still has to define message types, authorization, ordering and resynchronization. The protocol name does not establish the freshness of its underlying data or a provider's delivery guarantee.
A webhook is a server-to-server HTTP delivery to a receiver you operate. It is useful when account activity should trigger backend processing. It is not a browser transport: a visitor's browser is not normally a publicly reachable webhook receiver with a durable inbox.
| Mechanism | Useful role | Application still needs |
|---|---|---|
| REST reads | Initial state and reconciliation | Refresh and freshness policy |
| Webhooks | Notify backend of activity | Verification and durable handling |
| WebSocket | Send messages to connected clients | Authorization and reconnect recovery |
| Server-sent events | Push updates in one direction | Stream state and recovery policy |
The HTML standard defines server-sent events through EventSource and text/event-stream. They can be a simpler browser-facing choice when clients only receive updates. Reconnection behavior is not equivalent to a complete replay service unless your application retains and serves the required history.
What the MetaKit public API provides
As checked on 20 October 2026, MetaKit's public market/account interface uses REST routes and webhook deliveries. There is no documented public WebSocket or server-sent-event market-data subscription endpoint in that route contract. Internal remote-terminal WebSocket plumbing is a different feature and should not be treated as an account-data feed.
Relevant reads include /v1/accounts/{id}, /positions, /orders and /quote, nested under the account where applicable. For example, the quote resource is /v1/accounts/{id}/quote?symbol=EURUSD. Webhooks cover documented activity events; they are not a continuous quote stream. Confirm the exact event names and fields in the API reference.
Your own backend can combine those sources and expose its own authorized browser channel. That channel belongs to your application. Do not label an application-created wss:// route as a MetaKit endpoint or imply that forwarding polled snapshots turns them into every broker tick.
A practical data flow
Start with an authenticated user request to your backend. Resolve which account the user may view. Fetch the required snapshot through a server-side MetaKit credential, then return only the fields needed by the dashboard. Keep provider API keys out of browser JavaScript and browser storage.
Next, maintain a backend refresh process for that account. A verified activity webhook can mark the account view dirty; a bounded refresh reads the relevant state and publishes an application snapshot. Periodic reconciliation catches changes when an event is delayed or missed. The webhook reliability guide covers ingestion guarantees; this article concerns how the resulting state reaches viewers.
Define an application revision or snapshot identifier and attach an observation time. Those fields are yours, not a provider sequence number. A later application revision means your service published a later version; it does not prove every upstream intermediate event was observed.
For account views, sending the latest complete snapshot can simplify recovery. A browser replacing its old view with a new snapshot does not need to reconstruct positions from an assumed sequence of open/close messages. Keep immutable deal/audit records in a separate durable workflow rather than depending on every browser staying connected.
Share collection only inside an authorization boundary
Suppose twenty authorized viewers watch the same account, and each independently fetches a snapshot every four seconds. That is 300 upstream reads per minute: twenty viewers times fifteen refreshes. One backend collector on the same four-second schedule would make fifteen upstream reads per minute, then distribute its cached result to those viewers.
This is illustrative request arithmetic, not a MetaKit quota, a latency measurement or a recommended cadence. The collector must still perform the underlying work, enforce its concurrency budget and show when state is stale. A slower upstream observation cannot be made fresher by broadcasting it more often.
Share only where those viewers are entitled to the same data. Scope cache keys and subscriptions by tenant, account and permission level. Do not let a client select an arbitrary numeric account id and subscribe without an ownership check. Revalidate permissions when sessions expire or access changes.
The API key scopes guide explains the upstream credential layer. Your browser authorization is an additional application responsibility. A read-only provider key can still expose private account data if your backend broadcasts it to the wrong audience.
Plan for reconnects and slow viewers
When a viewer reconnects, obtain a fresh authorized snapshot rather than assuming the previous stream position is recoverable. If your application supports replay, define the retained range, revision semantics and what happens when the client is too far behind. Do not promise a provider replay capability that the upstream API does not supply.
For a display showing current equity or quotes, coalescing obsolete snapshots can protect a slow client from an ever-growing queue. Coalescing is inappropriate for a durable audit ledger that needs every recorded deal. Decide which message class you are sending before choosing the backpressure policy.
Mark disconnected and stale states visibly. A green WebSocket connection indicator only proves the browser connection exists; it does not prove the broker quote advanced. The quote-freshness guide separates those clocks. Include collection errors and observation times in your application view instead of retaining an old number under a new “updated now” label.
Test authorization failures, collector restarts, event bursts, viewer reconnects and deliberately slow clients with synthetic snapshots. Verify that upstream reads remain bounded as viewer count increases. No streaming implementation or performance benchmark is supplied here; the architecture and request calculation were checked against the current product interface and protocol roles.
Sources and verification
Verified 20 October 2026 against MetaKit's public router and webhook dispatcher.
- RFC 9110, HTTP semantics.
- RFC 6455, WebSocket protocol.
- HTML server-sent events, browser event-stream mechanism.
- MetaKit API documentation, supported public account and event interfaces.