Quick Start¶
From zero to a live order in about 10 minutes.
1. Grab the binaries¶
Handles macOS Gatekeeper automatically; all four production binaries end up on PATH. futu-indicator-worker is a pure-Rust helper launched by the gateway when needed.
# macOS Apple Silicon
curl -LO https://futuapi.com/releases/rs-v1.7.4/futu-opend-rs-1.7.4-macos-arm64.tar.gz
# Linux x86_64
curl -LO https://futuapi.com/releases/rs-v1.7.4/futu-opend-rs-1.7.4-linux-x86_64.tar.gz
tar xf futu-opend-rs-1.7.4-*.tar.gz
cd futu-opend-rs-1.7.4
macOS users: run once before first use to clear Gatekeeper quarantine: xattr -cr futu-opend futu-mcp futucli futu-indicator-worker
2. Start the gateway¶
./futu-opend \
--login-account 12345678 \
--login-pwd 'your_password' \
--rest-port 22222 \
--grpc-port 33333
First-time login on a new device will prompt for an SMS code on stdin. Credentials are cached to ~/.config/futu/ afterwards.
Success looks like:
INFO addr=0.0.0.0:11111 starting FutuOpenD Rust Gateway
INFO listen_addr=0.0.0.0:22222 REST API started (WebSocket: /ws)
INFO addr=0.0.0.0:33333 gRPC server started
3. Smoke test¶
# REST (legacy no-key HTTP; never send a Bearer token in this mode)
curl http://localhost:22222/api/accounts
curl http://localhost:22222/api/global-state
# CLI
./futucli --gateway 1.7.4.0.1:11111 quote HK.00700
./futucli --gateway 1.7.4.0.1:11111 accounts
# REPL
./futucli --gateway 1.7.4.0.1:11111 repl
# futu (1.7.4.0.1:11111) > sub HK.00700 -t basic,orderbook
# futu (1.7.4.0.1:11111) > quote US.AAPL
4. Turn on auth (strongly recommended)¶
Without auth, REST / gRPC / WS are wide open. Only OK for local dev. Use API keys in production:
# 1. Generate a read-only key
./futucli gen-key --id research --scopes qot:read,acc:read
# The terminal prints the plaintext: fc_xxxxxxxxxx...
# keys.json only stores a SHA-256 hash — keep that plaintext safe.
# 2. Restart gateway pointing at keys.json
./futu-opend \
--login-account 12345678 --login-pwd 'your_pwd' \
--rest-port 22222 --rest-keys-file ~/.config/futu/keys.json \
--rest-tls-cert /etc/futu-opend/rest-cert.pem \
--rest-tls-key /etc/futu-opend/rest-key.pem \
--grpc-port 33333 --grpc-keys-file ~/.config/futu/keys.json
# 3. REST now requires Authorization: Bearer
curl --cacert /etc/futu-opend/rest-ca.pem \
-H "Authorization: Bearer fc_xxxxxx..." \
https://localhost:22222/api/accounts
Scoped trading key with limits:
./futucli gen-key \
--id sim-bot \
--scopes qot:read,acc:read,trade:simulate \
--allowed-markets HK,US \
--max-order-value 100000 \
--max-daily-value 500000 \
--max-orders-per-minute 5 \
--hours-window 09:30-16:00 \
--expires 30d
5. Hook up an LLM (MCP)¶
# stdio mode (LLM client spawns it as a child process)
export FUTU_MCP_API_KEY="fc_xxxxxx..."
./futu-mcp --gateway 1.7.4.0.1:11111 --keys-file ~/.config/futu/keys.json
# HTTP mode (share one server across many LLMs, v1.0+)
./futu-mcp --gateway 1.7.4.0.1:11111 \
--keys-file ~/.config/futu/keys.json \
--http-listen 1.7.4.0.1:38765
# Prometheus scrape (no token)
curl http://1.7.4.0.1:38765/metrics
Register this MCP server in Claude / GPT and the LLM gains 170 tools for quotes, accounts and trading.
6. Monitoring + deploy¶
- Prometheus: legacy no-key mode scrapes
http://<rest-addr>/metrics; scope mode must scrapehttps://<rest-addr>/metrics, verify the daemon CA, and send a Bearer token withmetrics:readoradmin. - LB / k8s liveness: legacy no-key mode may call
http://<rest-addr>/livez; scope mode must callhttps://<rest-addr>/livezand verify the daemon CA./livezdoes not require a Bearer token, but it shares the TLS listener. Use/healthfor Platform/backend transport health and/readyzfor full gateway dispatch readiness. - Full Dockerfile + systemd units inlined in Production deploy
Production deployment tutorial →