# ccapi and the case for speaking to crypto exchanges directly

> ccapi is a header-only C++ library that connects your own server straight to cryptocurrency exchange servers for market data and order execution, with bindings for Python, Java, C#, Go and JavaScript. Its design copies Bloomberg's API shape and its trade-off is exchange-specific code you have to keep up with.

**crypto-chassis/ccapi** — A header-only C++ library for interacting with crypto exchanges. Bindings for Python, Java, C#, Go, and Javascript are provided.

- Repository: https://github.com/crypto-chassis/ccapi
- Website: https://discord.gg/b5EKcp9s8T
- Stars: 743 · Forks: 232
- Language: C++
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/crypto-chassis-ccapi

## The connection goes from your server to the exchange, with nothing in between

The definition in the project description is precise about the architecture. The library streams market data and executes trades directly from cryptocurrency exchanges, and the parenthetical is the important part: the connections are between your server and the exchange server without anything in between.

That is the whole design decision the library is built around. A hosted market data vendor or a brokered API would sit in the path and add a dependency, a fee and a rate limit. ccapi removes that layer, which means the code in your repository is the code that talks to the exchange, and every exchange quirk is your problem.

The consequence for a codebase is structural. You get one abstraction for subscribing to market depth, receiving trades and sending orders, and you get one place where exchange differences live. The supported venues are listed per capability, and the market data list includes ascendex, binance and its usds-futures and coin-futures variants, bitfinex, bitget, bitmart, bitmex, bitstamp, bybit, coinbase, cryptocom, deribit, erisx from Cboe Digital, gateio, gemini, huobi, hyperliquid, kraken, kucoin, mexc, okx and whitebit. The execution management list is nearly the same set, minus a few entries.

## The API shape is borrowed from Bloomberg on purpose

The project states that its code closely follows Bloomberg's API, and points at the Bloomberg API library documentation for the reference. That choice explains a lot about the interface, and it is the reason a developer with institutional experience can read ccapi examples without a translation step.

The vocabulary follows from that. There are sessions, subscriptions and requests, and the request types mirror the categories a professional market data terminal exposes: simple and advanced market data, simple and advanced execution management, and a separate FIX section. The FIX API is supported on three venues, binance, coinbase and gemini, which is a much narrower list than the market data coverage and tells you where the FIX work actually landed.

For an engineer choosing between this and an exchange's own official SDK, the comparison is about interface cost rather than capability. An official SDK covers one venue and gives you that venue's exact semantics. ccapi gives you one interface across many venues, at the price of a per-exchange adapter layer inside the library that you do not control.

## Subscriptions are the interesting half: depth, trades and two kinds of candle

The advanced market data section is where the library earns its complexity, and the section headings describe its vocabulary in full.

You can request complex request parameters, specify a subscription market depth, attach a correlation id to a request, and work with multiple exchanges and instruments in one call. From there the subscription event types branch out: periodic interval delivery, and a variant that also fires when the market depth picture has not changed, separate delivery of market depth updates, separate delivery of trade events, calculated candlestick events at periodic intervals, and exchange-provided candlestick events at periodic intervals.

Having calculated and exchange-provided candles side by side is the detail that matters for anyone doing intraday research. The two are computed on different schedules and can differ at the interval boundaries, and the library does not hide that difference behind a single type.

The generic request path is separate. You can send generic public requests, make generic public subscriptions, and send generic private requests, which is the escape hatch for endpoints the typed API does not cover yet. That gap is common in exchange client libraries, and having a documented generic path means a new exchange field usually does not require waiting for a typed method.

## Execution management has a blocking mode and a credential path

Order handling in ccapi is split into the simple and the advanced halves, with the advanced side adding the parameters that real order flow needs.

The advanced features listed are a correlation id, multiple exchanges and instruments, multiple subscription fields, a way to make Session::sendRequest blocking, a path to provide API credentials for an exchange, complex request parameters, sending a request over a Websocket API, and specifying the instrument type. Each of those is a concrete thing a production order router needs and a tutorial SDK usually omits.

The blocking mode is worth understanding as a design choice rather than a convenience. A sendRequest that returns a value has to block or the caller has to manage a future, and ccapi offers both shapes. The credential path matters for the same reason: keys for an exchange are passed through the library rather than assumed to come from an environment variable, which keeps the credential handling visible in the call site.

The instrument type parameter is the part to get right on day one. Spot, futures and perpetual swaps on the same venue can share a name, and specifying it incorrectly is the kind of error that shows up as a rejected order rather than as an exception.

## Header-only means fast to include and slow to compile

The build section is short and has real consequences. The library is header-only, an example CMake project lives at example/CMakeLists.txt, and the requirement is C++17 and OpenSSL. Service behaviour is switched on with macros in the compiler command line, with the named example being CCAPI_ENABLE_SERVICE_MARKET_DATA and the other family following the same pattern for execution services.

The benefit of header-only is that there is no library to link and no version to keep in step with a binary. The cost is compile time, and the project acknowledges it by carrying an example directory called example/reduce_build_time/, alongside example/test_cpu_usage/ and example/test_order_latency/ for the performance side. The example folder is unusually well organised overall, with one directory per documented feature: market_data_simple_request, market_data_advanced_subscription, execution_management_advanced_request, fix_simple, fix_advanced, heartbeat, set_timer, use_multiple_sessions, override_exchange_url_at_runtime and others.

The macro approach also means the enabled services are a compile-time choice. A build that does not define the market data service does not carry its code, which is how a trading system keeps its binary and its attack surface smaller, at the price of a longer build.

## The operational switches: logging, timers, heartbeats, proxies and session counts

A library that connects to live exchanges needs more than a request method, and the More Advanced Topics section lists the operational controls.

There is a section on handling events in immediate versus batching mode, which decides whether a callback fires per event or in groups. A thread safety section covers using the library from more than one thread. There is a switch to enable library logging, a way to set a timer, and a heartbeat capability, which for exchange connections is the difference between a session that is known alive and one that silently hangs.

Two more matter in practice. You can use multiple sessions, which is how a single process talks to several exchanges with separate credential sets, and you can override exchange URLs, which is the hook for a test environment or a proxy. Connecting to a proxy is a separate listed capability, and the example directory contains override_exchange_url_at_runtime for the runtime version of the same idea.

The project also keeps a Known Issues and Workarounds section, and a Performance Tuning section, both of which are the parts of a trading library documentation most worth reading before production use.

## Bindings, formatting scripts and how the project ships

The library is written in C++ but is not C++ only. Bindings for Python, Java, C#, Go and JavaScript are provided, and the repository has a binding/ directory alongside include/ for the headers and test/ for the tests. The bindings are generated or formatted by their own scripts: format_python.sh, format_java.sh, format_csharp.sh, format_go.sh and format_javascript.sh sit at the root next to format.sh, format_cmake.sh and format_cpp.sh, with a .clang-format file and a .cmake-format.yml governing style.

That script layout tells you something about the maintenance model. The bindings are kept in step with the C++ core by tooling, not by hand, which is the only way a header-only library can serve five languages without the wrappers drifting. It also means the C++ core is the place to look when a binding behaves differently.

The branch convention is explicit. The master branch represents the most recent stable release, and the develop branch may contain experimental features, so the default branch for the project, develop, is not the branch to pin a production build to.

The release history is frequent. v7.10.0 was published on 2026-08-02, v7.10.1 on 2026-08-07, and v7.10.2 on 2026-09-16, and the last push to the repository was on 2026-10-20. The licence is MIT.

## Conclusion

ccapi suits a trading or market data team that needs its own server talking straight to exchange servers, needs market depth and candlestick subscriptions across many venues, and is willing to maintain per-exchange code as the APIs change. It does not suit a team that wants a hosted feed, a brokered API or a managed trading platform, and it does not suit a project where a REST SDK in one language would do. Before adopting it, read the Known Issues and Workarounds section for the version you plan to pin, check the exchange specific notes for your venue, and note that the master branch is the stable release line while develop may carry experimental features, with v7.10.2 published on 2026-09-16 and the last push on 2026-10-20.

## FAQ

### What is ccapi and which exchanges does it support?

ccapi is a header-only C++ library for streaming market data and executing trades directly from cryptocurrency exchanges. The supported venue list covers binance, bitfinex, bitmex, bybit, coinbase, deribit, gateio, gemini, huobi, hyperliquid, kraken, kucoin, mexc, okx and others, with market data and execution supported on slightly different sets.

### How do I build ccapi and what does it require?

The library is header-only and requires C++17 and OpenSSL. An example CMake project is provided at example/CMakeLists.txt, and services are switched on with macros in the compiler command line, such as CCAPI_ENABLE_SERVICE_MARKET_DATA.

### Does ccapi have bindings for Python, Java, C#, Go and JavaScript?

Yes, bindings for those languages are provided and live in the binding/ directory of the repository. Formatting and maintenance scripts for each language are at the root of the project.

### Which branch of ccapi should I use for a production build?

The master branch represents the most recent stable release, while the develop branch may contain experimental features. The default branch recorded for the project is develop, so pin to master if you want the stable line.

### Which exchanges support the FIX API in ccapi?

The FIX API is supported on binance, coinbase and gemini. That is a much narrower list than the market data and execution management coverage, and the example directory carries both fix_simple and fix_advanced projects.

## Sources

- [crypto-chassis/ccapi on GitHub](https://github.com/crypto-chassis/ccapi)
- [License: MIT](https://github.com/crypto-chassis/ccapi/blob/develop/LICENSE)
- [Project website](https://discord.gg/b5EKcp9s8T)
- [README](https://github.com/crypto-chassis/ccapi/blob/develop/README.md)
- [Releases](https://github.com/crypto-chassis/ccapi/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/crypto-chassis-ccapi