> ## Documentation Index > Fetch the complete documentation index at: https://docs.reactor.inc/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Reactor hosts multiple models, each with its own connect slug (modelName) and command/event schema. The catalog of every model — slug, typed SDK package, and links to its schema — is at /model-api-reference/overview. Some models expose one slug per experience (e.g. HappyOyster); always take the slug from the model's own pages, never guess it. > Fastest path to a working app: `npx create-reactor-app my-app --model=` scaffolds a complete app with secure auth wired up. Typed TypeScript SDKs are published as @reactor-models/; Python uses the base reactor-sdk package. > Auth: exchange an API key (rk_...) for a JWT via POST https://api.reactor.inc/tokens from your server. Never put the API key in client-side code. > Append .md to any docs URL for clean Markdown. Search these docs via the MCP server at https://docs.reactor.inc/mcp. # Installation > Download a prebuilt archive, point CMake at it, and link one target The C++ SDK is a C++17 client built on the same Rust core the Python and JavaScript SDKs bind. It ships as **one prebuilt archive per platform** rather than through a package manager: the package is useless without its native library, and building that needs a Rust toolchain and a libwebrtc download — which is exactly what a consumer of a C++ SDK should not have to own. ## Platforms | Platform | Archive | Requires | | --------------- | ---------------------- | ---------------------------------------------------------------- | | Linux x86\_64 | `…-linux-x64.tar.gz` | glibc 2.34+ (Ubuntu 22.04, Debian 12, RHEL 9, Amazon Linux 2023) | | Linux aarch64 | `…-linux-arm64.tar.gz` | glibc 2.34+ | | macOS arm64 | `…-macos-arm64.tar.gz` | macOS 11+ | | macOS x86\_64 | `…-macos-x64.tar.gz` | macOS 13+ — libwebrtc's floor on this architecture | | Windows x86\_64 | `…-windows-x64.zip` | Windows 10+ | Every row is checked when the archive is built, not promised: the release refuses one that asks for a newer glibc, or that was built for a later macOS, than its row says. Anything outside the table — musl distributions, glibc older than 2.34, 32-bit, Windows on ARM — has no archive and has to [build from source](#building-from-source). ## Install Download the archive for your platform from the [releases page](https://github.com/reactor-team/reactor-client-sdks/releases), extract it, and point CMake at it: ```bash theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} tar xzf reactor-sdk-cpp-1.0.0-linux-x64.tar.gz cmake -S . -B build -DCMAKE_PREFIX_PATH=$PWD/reactor-sdk-cpp-1.0.0-linux-x64 ``` ```cmake theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} find_package(reactor-sdk REQUIRED) target_link_libraries(app PRIVATE reactor::sdk) ``` One target carries everything: the include directories, the C++17 requirement, `nlohmann_json`, and the native library. Nothing has to be set to run from your build tree. ```cpp theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} #include int main() { reactor::Reactor client{"reactor/helios", reactor::ApiKey{std::getenv("REACTOR_API_KEY")}}; client.connect().get(); // … client.disconnect().get(); } ``` A model name is `owner/name`. A bare name resolves under `reactor/`, so `"helios"` works by luck of ownership and answers 403 for anyone else's model — write the owner out. ## What is in the archive | Path | | | ------------------------------- | --------------------------------------------------------------------- | | `include/reactor/` | the public headers — you include `` and never the C header | | `lib/libreactor_sdk.a` | the SDK itself: a static library that disappears into your binary | | `lib/libreactor_ffi.{so,dylib}` | the native library — libwebrtc and the Rust core, **shared** | | `lib/cmake/reactor-sdk/` | the package config `find_package` reads | | `include/nlohmann/`, `share/` | `nlohmann_json`, unless you already have your own | On Windows the two halves are separate files: `lib/reactor_ffi.dll.lib` is what the linker reads and `bin/reactor_ffi.dll` is what the loader reads. The native library exports 29 symbols, all of them `reactor_*`. libwebrtc, BoringSSL, abseil and everything else it carries stay inside it, so nothing collides with what your application already links. ## Shipping your application `libreactor_sdk.a` is static and disappears into your binary. `libreactor_ffi` is shared, so it stays a separate file and has to travel with what you ship. The rpath CMake gives your binary in the build tree is an absolute path on the machine that built it. For an installed application, say it relatively and put the library where it points: ```cmake theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} set_target_properties(app PROPERTIES INSTALL_RPATH "$,@loader_path,$ORIGIN>") install(TARGETS app RUNTIME DESTINATION bin) install(FILES "$" DESTINATION bin) ``` `$` is the `.so`, the `.dylib` or the `.dll` — the file that runs, on every platform. Windows needs no rpath; the DLL beside the executable is how the loader finds it. ## Runtime dependencies `libreactor_ffi` loads `libc`, `libm`, `libgcc_s` and the dynamic loader on Linux, and that is the whole list — TLS is rustls, so there is no OpenSSL, and libwebrtc is linked statically inside it. The one exception is [audio devices](/sdk-reference/cpp/audio-devices), which are an opt-in target. ## Building from source Only needed for a platform with no archive, or to work against a local change to the core. ```bash theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} git clone https://github.com/reactor-team/reactor-client-sdks cd reactor-client-sdks mise run build:ffi # cargo build -p reactor-ffi --release mise run build:cpp # cmake + ninja ``` Building the native library is a separate step, not a dependency of the SDK build. On Linux it compiles libwebrtc's C++ glue with a pinned clang whose sysroot cannot resolve what the resulting `.so` needs from the system glibc, so the SDK itself is built with the platform compiler. Two compilers, two commands. To build against a library somewhere else — a release archive's `lib/`, or another checkout: ```bash theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} cmake -S sdks/cpp -B build -DREACTOR_FFI_LIB_DIR=/path/to/lib ``` Rebuild the native library after pulling changes to the core. A signature that moved in the FFI but not in your build still links, and then corrupts the stack at the call — which looks like a hang, not a version error. The SDK checks `reactor_abi_version()` at startup and turns that into a message naming both versions, but only if the library on disk is the one you think it is. ## Next Connecting, commands, uploads, recordings, events. Pushing frames, receiving them, pausing, bitrate. `Status`, `ReactorError` and its codes, `Clip`, `Subscription`. `Speaker` and `Microphone`, in a target nothing links by accident.