> For the complete documentation index, see [llms.txt](https://developer.barchart.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.barchart.com/getting-started/best-practices.md). # Best Practices ### 1. Selecting the Right SDK for Your Use Case The Streaming Openfeed API allows you to receive market updates based on two subscription types: 1) Full-pipe Exchange Feed; 2) Symbol-limited Feed. To optimize your application's performance, choose your Openfeed SDK based on the stream's volume and role in your application architecture. * **Full-pipe exchange feeds:** Use **Java, .NET, or Go**. These lower-level languages are better suited for high-throughput feed handling, large packet volumes, and production-grade ingestion services. * **Symbol-limited subscriptions:** Any SDK can work well, including **Python** and **JavaScript**, since performance demands are much lower. As a best practice, use **Java, .NET, or Go** for the primary market data feed handler, and use **Python** for ETL, analytics, ML/AI, and data operations or **JavaScript** for front-end visualization and user-facing applications. {% hint style="info" %} For more information, visit the [Streaming API](/openfeed-api/streaming.md) documentation or review the [Installing the SDK](/repos-sdks/installing-the-sdk.md) page. {% endhint %} #### Subscribing to Full Exchange For **full-pipe exchange subscriptions**, choose a **lower-level, high-performance language** such as **Java, .NET, or Go**. This use case is the most demanding because the application must continuously process **large packet volumes**, including instrument definitions, metadata, and rapid real-time market updates. In these scenarios, the SDK is typically being used as a **feed handler** or as part of a core **market data ingestion and distribution layer**, where throughput, memory efficiency, concurrency, and connection stability matter most. Higher-level languages are generally **not recommended** as the primary feed handler for full-pipe exchange feeds. For example, **Python** is excellent for ETL workflows, downstream analytics, ML/AI applications, and data pipeline orchestration, but it is not the best fit for handling heavy real-time exchange streams directly. Likewise, **JavaScript** is well-suited for browser-based applications, dashboards, and front-end market data visualizations, but it is not intended to serve as the backbone of high-volume streaming infrastructure. #### Subscribing Symbol-by-Symbol For **symbol-by-symbol** or otherwise **limited subscriptions**, any of the Openfeed SDKs can be a reasonable choice. When message volume is constrained, language selection can be driven more by **team preference, existing system architecture, and the end use case** than by raw streaming performance. In these lighter streaming scenarios, **Python** is often a strong choice for prototyping, research, ETL (Extract, Transform, Load), analytics, and AI-driven workflows. **JavaScript** can work well for client-side applications and interactive charting or visualization layers. **Java, .NET, and Go** remain strong options when the application may later expand into more demanding production workloads or when consistency with backend systems is important. ### 2. Build API-Specific Metadata Workflows Openfeed provides two primary API access methods: **Streaming API** and **REST API.** Each is designed for different application workflows while being powered by the same underlying Openfeed infrastructure. Both APIs are sourced from the same core **Openfeed protocol, market data normalization layer, and exchange connectivity**, ensuring consistency in instrument definitions, metadata, and market data value. The approach to retrieving instrument metadata differs between the **Streaming API** and the **REST API**, reflecting their different delivery models. 1. Streaming API 2. REST API With the **Streaming Openfeed API**, instrument metadata is automatically returned when a client establishes a subscription. The platform sends **`instrumentResponse`** and **`instrumentDefinitions`** message packets containing the instrument definitions and structural details for each subscribed symbol. This allows the client application to immediately understand how to interpret the market data messages that follow. In contrast, the **Snapshot REST API** follows a query-based model, so instrument metadata is **not automatically included** with market data responses. Clients must retrieve instrument definitions through a **separate metadata workflow** before or alongside their data queries in order to properly interpret the returned data. ### 3. Monitor Your Connection When monitoring an application connected to the **Streaming Openfeed API**, treat the connection as more than just a live socket. A healthy implementation should monitor both **session-level messages** and **data-level messages** from the `OpenfeedGatewayMessage` stream to confirm that the application is authenticated, subscribed correctly, receiving expected metadata, and continuing to process live updates without interruption. #### Session-Level Monitoring At the **session level**, clients should monitor messages such as **`loginResponse`**, **`logoutResponse`**, **`subscriptionResponse`**, **`exchangeResponse`**, and **`listSubscriptionsResponse`** to verify that the application successfully connected, authenticated, and established the expected subscriptions. Messages such as **`instrumentResponse`**, **`instrumentReferenceResponse`**, **`instrumentDefinition`**, and **`instrumentAction`** should also be tracked, as they confirm that the application has received and retained the instrument metadata required to interpret downstream market data correctly. **Logging On and Off the Stream** Client applications should avoid making rapid, consecutive login attempts after a dropped connection. If multiple login sessions are initiated too quickly using the same username, the Openfeed system may detect overlapping or duplicate sessions and terminate both connections as a security safeguard. To prevent this scenario, applications should implement connection monitoring and controlled retry logic rather than immediately attempting to reconnect. Implementing the Heartbeat protocol can help detect connection issues earlier and reduce unnecessary reconnect attempts. In addition, clients should monitor loginResponse and logoutResponse messages to track session state and confirm whether a login or logout event has been processed successfully before initiating a new connection. These response messages provide the necessary feedback to ensure that login, logout, and subscription events are handled in a controlled and reliable way. To avoid any scenarios of overlapping or duplicate logins of a user. Do not immediately log in again after a dropped connection. The system detects multiple instances of the same username and drops both for security reasons. You may be able to avoid hard connect-reconnect cycles if you have our HeartBeat proto in place. \ \ Use the the `openfeed_api.proto` to properly login, log out, and validate your authentication sequeuce. * [LoginRequest](https://docs.barchart.com/openfeed/#/proto?id=loginrequest) * [LoginResponse](https://docs.barchart.com/openfeed/#/proto?id=loginresponse) * [LogoutRequest](https://docs.barchart.com/openfeed/#/proto?id=logoutrequest) * [LogoutResponse](https://docs.barchart.com/openfeed/#/proto?id=logoutresponse) * [SubscriptionRequest](https://docs.barchart.com/openfeed/#/proto?id=subscriptionrequest) * [SubscriptionRequest.Request](https://docs.barchart.com/openfeed/#/proto?id=subscriptionrequestrequest) * [SubscriptionResponse](https://docs.barchart.com/openfeed/#/proto?id=subscriptionresponse) * [Result](https://docs.barchart.com/openfeed/#/proto?id=result) #### Connection-Health Level At the **connection-health level**, **`heartBeat`** messages are one of the most important signals to monitor. The server sends heartbeat messages at regular intervals, and your application should alert if a heartbeat is not received within the expected time window. This helps detect silent failures such as network disruption, dropped sessions, or stalled consumers before they create downstream data gaps. **Implement Heartbeat Monitoring** Client applications should implement the **Openfeed Heartbeat protocol** to monitor the health of the streaming connection. The Openfeed server sends a **heartbeat message every 10 seconds**, allowing your system to verify that the feed connection is still active. If a heartbeat is not received within the expected interval, it may indicate a network interruption or dropped connection. Your application should detect this condition, trigger an alert, and initiate appropriate recovery logic such as reconnecting to the feed. For implementation details, refer to the Openfeed protocol documentation [openfeed.proto](/architecture/openfeed-proto.md) #### Market-Data Level Monitoring At the **market-data level**, clients should monitor the flow of messages such as **`marketStatus`**, **`marketSnapshot`**, **`marketUpdate`**, **`volumeAtPrice`**, and **`ohlc`** to confirm that the stream is actively delivering data. Best practice is to track message rates, timestamps, and processing latency for these packets so your team can distinguish between a normal market lull and an application, subscription, or feed issue. A robust monitoring strategy should combine these protocols into a layered set of checks: confirm the session is authenticated, confirm subscriptions were accepted, confirm heartbeat traffic is active, confirm metadata was received, and confirm live market data continues to flow. Together, these signals provide the clearest picture of whether the Openfeed connection is healthy, stale, degraded, or disconnected. ### 4. Optimize Your Configuration to Keep Up with MarketSnapshots and MarketUpdates Client applications should be designed to keep pace with the rate of incoming **`MarketSnapshot`** and **`MarketUpdate`** messages, especially during periods of heavy market activity. A best-practice implementation should assume that message volume can increase rapidly and should use efficient * Parsing * Buffering * Multi-threaded or asynchronous processing If the client cannot process messages fast enough, packets may begin to queue internally, increasing latency between when data is sent by Openfeed and when it is actually consumed by the application. #### Intermittent Queuing When a client falls behind, the first risk is not always a broken connection, but a **stale one**. The application may still appear connected while it is processing an ever-growing backlog of delayed messages. This can also make message handling more difficult if downstream systems expect events to be processed in near real time. In high-volume conditions, clients should monitor queue depth, message-processing lag, and end-to-end latency so they can detect when the application is no longer keeping up with the feed. #### Reasons for Application Disconnections Applications should also be built with the understanding that market data messages must be handled in the correct sequence. If processing slows down or messages are mishandled, the client can create an internal state where updates are effectively applied out of order relative to the intended stream. Once the backlog becomes too large, the safest recovery pattern is often to **disconnect, clear the stale state, reconnect, and resubscribe** so the application can reestablish a current view of the market rather than continue processing delayed data that is no longer actionable. ### 5. Using Barchart's Market Replay API or Enterprise File Service as a Fallback Any production-grade market data application should include a **fallback or backup data strategy** in case the primary streaming connection is interrupted, delayed, or otherwise degraded. Even with strong connection monitoring and recovery logic, firms should plan for scenarios such as network disruption, client-side processing issues, exchange-side events, or temporary infrastructure failures. A resilient architecture does not rely on a single live stream alone; it also includes a secondary method for recovering missed data and maintaining continuity across downstream systems. Barchart can support this recovery workflow through products such as the [**Market Replay API**](https://www.barchart.com/solutions/services/market-replay-api) or [**Enterprise File Service**](https://www.barchart.com/solutions/services/market-replay-enterprise). These services can be used as a fallback source to help backfill missing intervals, restore gaps caused by a disconnected or lagging client, and rebuild a clean historical record after an outage. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://developer.barchart.com/getting-started/best-practices.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.