Developers
Extend Voxta two ways: .NET modules that run inside the server, or client integrations that connect over the WebSocket API. Start here.
Voxta has two extensibility paths, and they live in different runtimes:
- Modules are .NET class libraries that run inside the Voxta server process. Every built-in LLM provider, voice, transcriber, and vision service is a module. You write a module when your code can sensibly live as .NET running next to the rest of the server — wrapping an API, watching a file, sending a keypress, hitting an HTTP endpoint.
- Integrations are separate processes that connect to Voxta over the WebSocket / SignalR API. The Minecraft Companion (Electron + Node.js), the VAM plugin (in-game C# script), and Voxy (desktop avatar app) are integrations — they live where their host runtime lives. You build an integration when your code needs to run somewhere Voxta can't: a game's scripting engine, a Node.js bot, a browser, a Python add-on.
Both paths consume the same characters, LLMs, voices, and scripts you've configured in Voxta — they just plug in at different layers.
Building a module
Modules
What a Voxta module is, how to build one, how it plugs into the server.
SDK
The four NuGet packages that make up the public Voxta SDK.
Building a client
Client API
Connect over the WebSocket hub: authenticate, start a chat, follow what the character does.
Client tools
Declare tools the character can call and run them in your app.
Reference example
Existing integrations
Most of the integrations Voxta ships are open-source (Voxy's source is currently closed) and double as examples of how to consume the Voxta API from outside the server: