LongPort Programmatic Trading & Market Data Interface (SDK)

This LongPort OpenAPI SDK suite offers developers robust, low-latency interfaces for executing quantitative trading logic and accessing market intelligence. It is designed for users capable of developing custom research and algorithmic tools based on proprietary investment methodologies. Core capabilities are segmented as follows:

• Trade Operations: Full lifecycle management for securities orders (placement, modification, cancellation), historical and intraday trade record retrieval, etc.
• Market Data Access: On-demand retrieval of current pricing snapshots and extensive historical time-series quote data.
• Asset Monitoring: Real-time status checks for account holdings, available capital, and security positions.
• Streaming Data: Persistent connections for immediate quote updates and asynchronous notifications regarding order execution status changes.

Available Language Bindings & Implementations:

Language Platform	Reference Documentation	Minimum Version Requirement
[Rust]	[API Docs Link]	Rust >= 1.89.0
[Python]	[API Docs Link]	Python 3 >= 3.7
[Node.js/JS]	[API Docs Link]	Node.js >= 10
[Java]	[API Docs Link]	Java >= 1.8
[C]	[API Docs Link]	C99 Standard
[C++]	[API Docs Link]	C++17 Standard
Go Lang	[GitHub Repo Link]	N/A
[Message Channel Protocol (MCP)]	[MCP Server Guide]	N/A (Server Implementation)

Configuration Parameters (Environment Variables)

Variable Name	Purpose	Default Setting
LONGPORT_LANGUAGE	Interface locale setting (zh-CN, zh-HK, or en).	en
LONGPORT_APP_KEY	Required application authorization key.	N/A
LONGPORT_APP_SECRET	Confidential application secret credential.	N/A
LONGPORT_ACCESS_TOKEN	Session authorization token for authenticated access.	N/A
LONGPORT_HTTP_URL	Primary endpoint URI for RESTful API calls.	https://openapi.longportapp.com
LONGPORT_QUOTE_WS_URL	WebSocket URI for receiving streaming market price data.	wss://openapi-quote.longportapp.com/v2
LONGPORT_TRADE_WS_URL	WebSocket URI for receiving real-time trade execution notifications.	wss://openapi-trade.longportapp.com/v2
LONGPORT_ENABLE_OVERNIGHT	Boolean flag to include overnight trading session quotes.	false
LONGPORT_PUSH_CANDLESTICK_MODE	Defines candlestick calculation basis: realtime or confirmed.	realtime
LONGPORT_PRINT_QUOTE_PACKAGES	Verbosity flag to output raw quote data packets upon connection.	true
LONGPORT_LOG_PATH	Specifies the file system location for generated system diagnostics/logs.	System default (no logging)

Comprehensive Documentation Portal

Official SDK Documentation Index: https://longportapp.github.io/openapi

Auxiliary References

• LongPort Public Portal
• Developer Documentation Portal

Licensing Terms

Distribution is governed under the mutual terms of either:

• Apache License, Version 2.0, (See: APACHE LICENSE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT License, (See: MIT LICENSE or http://opensource.org/licenses/MIT)

[Historical Context on Asynchronous HTTP Requests (XMLHttpRequest)]

XMLHttpRequest (XHR) is a foundational JavaScript Application Programming Interface (API) implemented as a browser object. Its methods facilitate the transmission of HTTP requests from a client-side script to a backend server after the initial page load, enabling dynamic data retrieval and submission without full page reloads—a core principle of Asynchronous JavaScript and XML (Ajax). Before XHR, server interaction heavily relied on traditional hyperlink navigation or form submissions, which inherently caused screen refreshes.

The genesis of the XHR concept dates back to 2000, pioneered by Microsoft Outlook developers. Its initial manifestation appeared in Internet Explorer 5 (1999), although using proprietary COM object instantiations (ActiveXObject("Msxml2.XMLHTTP")). By the release of IE7 (2006), cross-browser compatibility solidified around the standardized XMLHttpRequest identifier. This identifier subsequently became the universal standard across major browser engines, including Mozilla's Gecko (2002), Safari (2004), and Opera (2005).

=== Standardization Evolution ===

The World Wide Web Consortium (W3C) formalized the specification, releasing a Working Draft in April 2006. Level 2 advancements arrived in February 2008, introducing capabilities for monitoring data transfer progress, enabling secure cross-domain communication, and processing binary data streams. The Level 2 feature set was ultimately merged back into the primary specification later that year. Development stewardship was transferred to the WHATWG near the end of 2012, which now maintains the active specification using Web IDL definitions.

== Operational Workflow ==

Executing a typical XHR operation involves a sequence of programming steps:

1. Instantiation: Create a new XMLHttpRequest object instance.
2. Configuration: Invoke the open() method to define the request method (GET/POST/etc.), target URL, and whether the operation should be blocking (synchronous) or non-blocking (asynchronous).
3. Asynchronous Handler Setup: For asynchronous operations, register an event listener function to be triggered upon state transition.
4. Transmission: Start the data transfer by executing the send() method, optionally including payload data.
5. Response Processing: Monitor the object's readyState property within the listener. Upon reaching state 4 (the "done" state), the server response is available, typically in the responseText property, ready for parsing.

Beyond these fundamentals, XHR offers fine-grained control: custom HTTP headers can set server expectations; data can be uploaded efficiently; responses can be immediately parsed as structured JSON; and requests can be terminated early or given strict timeouts.