AllTick market data API: REST for history, WebSocket for the tape

One hosted feed for six asset classes

AllTick is a commercial market data service, not a library you add to a build. The README describes it as a financial market data API provider giving programmatic access to real-time and historical data, and the stated audience is developers, fintech applications, quantitative teams, trading platforms, financial analytics and other data-driven products.

Coverage is the first thing to check. The README lists stocks, forex, cryptocurrency, precious metals, oil and commodities, and global indices. Within stocks it names US stocks, Hong Kong stocks and A-shares. Within precious metals it names gold and silver. That level of detail is unusual for a vendor landing page, and the repository carries matching machine-readable product code lists per market: separate files for A-shares, Hong Kong stocks, US stocks, gold, cryptocurrency and forex, each with a Chinese counterpart.

Those files matter more than the marketing blurb. An API is only useful if it covers the instrument you actually trade, and the product code lists are where that question gets answered. The README also notes that order book data is available for forex "where available", a small but telling qualifier in a section otherwise presented as uniform coverage.

Two interfaces split by request type, not by asset class

The architecture in the README is a fork in one place: your application calls the AllTick API, and the API splits into a REST branch and a WebSocket branch. The REST branch carries latest quotes, historical data and K-line data. The WebSocket branch carries real-time tick, trade-by-trade and order book depth.

That split is the practical design decision in this service. REST suits requests that arrive on their own schedule, such as pulling a day's K-line series for a chart or fetching the latest quote for a watchlist page. The socket suits a process that wants to be pushed every update as it happens, which is what a live dashboard or a market monitoring service needs.

Note what this means in practice. A REST client is easy to reason about: request, parse, repeat on a timer. A WebSocket client has to handle a persistent connection, and the repository's own list of interface directories, including websocket_interface/ alongside http_interface/ and rest_interface/, shows that the protocol surface is documented separately from the request endpoints.

The README also frames the choice for you in its own terms: use REST for request-based access, use WebSocket for real-time streaming. Nothing in the documentation describes a combined endpoint that returns both.

Four data types are documented across the two interfaces: real-time quotes, tick data, order book data and K-line data. Tick data and trade-by-trade streaming are what separate this kind of feed from a simple price lookup service.

Getting in starts with a token application, not a package install

There is nothing to install from this repository. The quick start is a documentation path, and it begins at the vendor site:

https://alltick.co
https://alltick.co/apis/en

The first URL is the product site and the second is the API documentation. Step three of the quick start is to apply for API access by following the access and token application documentation that the repository includes and the vendor site repeats. The relevant files are token_application.md and access_guide.md, each with a Chinese version alongside it.

After that the quick start has you pick REST or WebSocket, then integrate using the examples in the repository. The examples are grouped by language, with directories for Python, PHP, Go and Java, and the README says the same four languages structure the interface documentation. The repository is primarily written in Java, which reflects the example code rather than a Java client library: there is no published package to add to a project, only sample integrations you copy.

The documentation set is unusually complete for a vendor repository. Alongside the two READMEs there are FAQ.md, ARCHITECTURE.md, llms.txt, which the README describes as AI and machine-readable information, error_code_description.md for decoding API errors, and a set of governance files covering contributing, security, support and citation metadata.

A documentation repository, with no licence file listed

The top level of the repository is the honest signal about what this project is. There is no src directory, no build configuration and no package manifest for a client. What sits at the top instead is documentation: an architecture note, a changelog, a citation file, a code of conduct, a contributing guide, a security policy, a support guide, an access guide, an error code description, the interface directories and the product code lists.

That shape has consequences for an engineer choosing between this and a self-hosted pipeline. You get endpoint definitions, error codes, symbol lists and worked examples, which is a lot of integration surface. You do not get a maintained SDK that handles reconnection, backoff, authentication refresh and schema drift for you, because the repository does not contain one. Every consumer writes that layer.

Licence is the other gap, and it is a real one for a commercial data provider. The repository files listed at the top level contain no LICENSE file, and the licence for this project is not stated. The README carries a licence badge linking to the GitHub licence page, but the actual terms are not in the tree. Anyone planning to redistribute examples, embed the code lists in a product, or resell derived data needs to resolve that question with the vendor in writing first.

For a service whose output is market data, the terms on redistribution and derived works are usually more consequential than the terms on the example code, and neither can be read here.

Where the API is the wrong tool

The clearest limit is operational. Every quote depends on the vendor's infrastructure and on the token you were granted, and the README does not describe any local cache, replay store or failover path. A backtest that must reproduce a past tape byte for byte is a poor fit for a live feed, and the historical access described here is K-line and time-series retrieval rather than a documented tick archive.

Symbol coverage is the second limit. The product code lists exist because coverage is finite, and the forex section concedes that order book data is only present for some pairs. Any strategy that assumes a uniform depth feed across every market and every symbol has to be checked against those lists first.

The third limit is the one implied by the repository's own age markers. The most recent tagged release is V1.0.3 from 2024-03-27, with V1.0.2 and V1.0.1 both from March 2024, yet the last push was on 2026-09-28 and the repository is not archived. Documentation repositories often move without new tags, so the changelog and the interface directories are more informative about currency than the release list is. Nothing in the tree promises a versioning policy for the API itself.

Polling REST versus holding a socket, and the direct-venue alternative

The real choice for a builder is between two shapes of the same problem. If you poll the REST endpoints on a timer, you control the request cadence, you need no persistent connection, but you only see what you asked for and the gaps between polls are yours to own. If you hold the WebSocket connection, updates arrive as they happen and tick and trade-by-trade data become available at all, but now your process owns reconnection, heartbeats and the ordering of messages that arrive while you are disconnected.

The second alternative sits outside this service entirely: connect to each exchange or broker feed directly and aggregate the venues yourself. The difference in approach is where the complexity lives. AllTick centralises the venue problem behind one token and one protocol pair, and in exchange you accept a hosted dependency and its pricing. Going direct keeps the raw source close, gives you the venue's own semantics for each instrument, and hands you the reconciliation work across markets, symbols and trading hours.

For a single asset class on one venue, direct is often the cheaper answer. For a product that needs stocks, crypto, forex and metals in one place with one integration, the unified API is the point of the service, and the README's whole structure, with one product code list per market and one documentation set per interface, is built around that breadth.

Editorial conclusion

AllTick fits a team that wants one hosted feed for several asset classes and would rather write HTTP and socket clients than connect to each venue separately. It does not fit a project that needs a self-hosted data path, a published client library, or a licence it can audit, since no licence file is listed among the repository files and the release tags stopped at V1.0.3 in March 2024 even though the last push was on 2026-09-28. Before committing, read token_application.md and access_guide.md to learn what the token requires, then confirm with a live quote request whether the specific symbols you need appear in the matching product_code_list file for that market.

Frequently asked questions

Official sources

1. AllTick-Official/alltick-realtime-forex-crypto-stock-tick-finance-websocket-api on GitHub
2. Issues
3. Project website
4. README
5. Releases