Most market data APIs look simple on the surface, one URL, one symbol, one latest price. Under load, that simplicity breaks: URL length limits, rate limits, cross‑asset fragmentation, and unreliabl

Most market data APIs look simple on the surface, one URL, one symbol, one latest price. Under load, that simplicity breaks: URL length limits, rate limits, cross‑asset fragmentation, and unreliable websockets turn a neat prototype into a fragile production system.

Alltick’s HTTP GET /trade-tick and its companion WebSocket endpoints are designed to solve the boring but critical problems around how you actually move real‑time tick data into a trading or analytics stack at scale. This article walks through what the interface really does, why the limits are structured the way they are, and how to think about Alltick as a primary ingress layer for stocks, forex, crypto, and precious metals.

One Interface, Two Base Paths: Equities vs. Everything Else

The first design choice is separation by asset universe while keeping the same semantics:

• Stocks and indices
• Base path: /quote-stock-b-api/trade-tick
• Full URL: https://quote.alltick.co/quote...
• Forex, precious metals, crypto, commodities
• Base path: /quote-b-api/trade-tick
• Full URL: https://quote.alltick.co/quote...

Semantically, both endpoints behave the same: they return the latest trade tick for one or more instruments, not historical tick series. The split is practical:

• It allows internal scaling and routing by asset universe without changing the client contract.
• It lets you map your infra cleanly: one set of consumers for stocks/indices, another for FX/crypto/commodities, or a unified client that simply chooses the URL based on symbol.

From a client point of view, this means your code can treat “latest tick for 857.HK” and “latest tick for XAUUSD or BTCUSDT” in a unified way—only the base URL differs.

Batch Tick Retrieval: URL‑Encoded JSON Instead of Ad‑Hoc Query Strings

The HTTP pattern is:

text

GET https://quote.alltick.co/quote...

GET https://quote.alltick.co/quote...

Where queryData is a URL‑encoded JSON blob, for example:

json

{

 "trace": "edd5df80-df7f-4acf-8f67-68fd2f096426",

 "data": {

  "symbol_list": [   { "code": "857.HK" },   { "code": "UNH.US" }  ]

 }

}

This design has a few important implications:

• Traceability is built in.
• Every request carries a trace field that is mirrored back in the response. That makes correlation and debugging across your system trivial—no guessing which response belongs to which upstream call.
• Symbol batching is explicit and structured.
• You pass a symbol_list array under data, each with a code field. Alltick’s code lists (A‑shares, HK, US, crypto, forex, commodities, etc.) give you canonical identifiers you can map directly from your instrument universe.
• You avoid query‑string combinatorial explosions.
• Instead of inventing your own symbol=...&symbol=... syntax and worrying about parsing, you work with a single JSON document that your client can easily construct and validate before encoding.

Rate Limits That Match Real‑World Throughput Needs

The documentation specifies different rate limits by plan tier (Free, Basic, Premium, Professional, All HK Stocks, All CN Stocks). Although the exact numbers vary, the pattern is consistent:

• Per‑second request caps (e.g., 1, 10, 20 req/s).
• Per‑minute aggregates (e.g., 10, 600, 1200 req/min).
• Daily ceilings with automatic midnight resets.

A few practical takeaways:

• You’re meant to batch.
• The docs explicitly “suggest 50 code requests max due to GET URL length limit.” That’s a hint: design your client to request multiple symbols per call, not spam one instrument per request.
• Limits are shared across interfaces.
• Phrases like “combined interfaces: 10 requests/second” mean your HTTP calls share the same bucket as other endpoints on that token. This is exactly how you’d want to design a fair, predictable API for high‑volume clients.
• The progression across tiers is linear.
• Moving from Free to Basic to Premium to Professional simply scales your allowable QPS and daily volume. You do not need to rewrite client logic when you upgrade; you just lift the throttle.

For engineering teams, this makes Alltick straightforward to integrate into existing rate‑limiting and backoff mechanisms—no weird, undocumented edge cases.

Response Shape: Tick‑First, Transport‑Agnostic

A successful trade-tick call returns:

json

{

 "ret": 200,

 "msg": "ok",

 "trace": "edd5df80-df7f-4acf-8f67-68fd2f096426",

 "data": {

  "tick_list": [   {    "code": "857.HK",    "seq": "30841439",    "tick_time": "1677831545217",    "price": "136.302",    "volume": "0",    "turnover": "0",    "trade_direction": 0   }  ]

 }

}

A few things to notice from an implementation standpoint:

• Consistent envelope: ret, msg, trace, data.
• This is the same pattern you’d use across endpoints, simplifying client deserialization.
• Tick is the core unit.
• Inside tick_list, each object is a complete latest‑trade record:
• code: instrument code
• seq: sequence number
• tick_time: epoch millisecond timestamp
• price, volume, turnover
• trade_direction: 0 (default), 1 (BUY), 2 (SELL)
• Stringified numerics.
• Prices and volumes are strings, which avoids floating‑point issues in transport and lets client libraries choose their numeric representation (decimal, BigInt, etc.).

Because this format is transport‑agnostic, you can ingest it into almost any stack—Python, Go, Rust, Java—without worrying about type mismatches. The seq and tick_time fields also make it easy to detect staleness or out‑of‑order updates on your side.

WebSocket: Turning Polling into a Stream

HTTP is ideal for on‑demand snapshots and low‑frequency monitoring, but real trading systems lean on streaming. Alltick exposes two key WebSocket endpoints:

• Stocks
• wss://quote.alltick.co/quote-stock...
• Forex, crypto, precious metals, commodities
• wss://quote.alltick.co/quote-b-ws-...

Once the connection is established with a valid token, you subscribe to specific streams (ticks, order book, etc.) using the documented WebSocket interface list. The HTTP design and WebSocket design are clearly meant to mirror each other:

• Same asset splits (stocks vs FX/crypto/metals/commodities).
• Same token model.
• Shared concepts (tick, order book, heartbeat, cancel subscription).

From an architecture perspective, this lets you:

• Use HTTP trade-tick for cold starts, periodic sanity checks, and monitoring.
• Use WebSocket for low‑latency streaming into trading engines, dashboards, and alerting systems.
• Share the same instrument coding and mapping logic across both.

Why This Matters From a System Design Perspective

For a more technical audience, the value proposition of Alltick is less about “we have data” and more about how this interface design reduces friction:

• Unified, multi‑asset ingress.
• The same client can hit U.S. stocks, HK stocks, A‑shares, indices, FX, crypto, commodities, and precious metals just by changing base paths and codes.
• Predictable limits for capacity planning.
• Clear QPS and daily caps by tier mean you can design your own internal batching and throttling with confidence, rather than guessing how hard you can push the API before it breaks.
• First‑class traceability.
• The trace field is not an afterthought. It’s part of the contract, which is what you want when tying live trading systems into third‑party data.
• Transport symmetry.
• HTTP and WebSocket are aligned enough that you can switch between snapshot‑pull and stream‑push modes without rewriting your domain logic.

A Concrete Way to Experiment With Alltick’s Tick API

If you want to evaluate Alltick from a more professional, infra‑aware angle, a simple experiment is:

Start with HTTP trade-tick:

• Build a small service that queries 20–50 symbols (a mix of stocks, FX, crypto, metals) every second using the appropriate base path.
• Log trace, seq, tick_time, and price for each symbol.

Add WebSocket streaming:

• Connect to quote-stock-b-ws-api and quote-b-ws-api with your token.
• Subscribe to the same instruments and compare stream latency and consistency against HTTP snapshots.

Stress your own systems, not just the API:

• Move from Free to a higher tier if needed, and see how your internal processing pipeline handles 10–20 requests per second and higher tick throughput.

You will learn very quickly whether Alltick’s design fits your latency, stability, and observability requirements—using your own tooling and metrics, not just marketing claims.