Skip to content
Console
Try one

    Developer Docs

    Build a voice skill, or connect your app to a Thalovant hub with an SDK.

    There are two things you can build here, and they are different jobs.

    A skill runs on the hub and answers a particular kind of request — the code behind “what’s the weather?”. An SDK is a library your own app uses to send requests to a hub and read the answers.

    Pick the tab for your language. Every SDK does the same four things: sign in, create a client identity on a hub, connect over WSS, ask. The reply’s text is what the hub would have said out loud.

    from thalovant import ThalovantClient, ThalovantControlPlane
    api = ThalovantControlPlane()
    hub = api.list_public_hubs(limit=1)["data"][0]
    print(hub["title"], hub["slug"])
    api.login("[email protected]", "password")
    result = api.create_client_identity(
    hub["id"],
    name="python-demo-client",
    preferred_protocols=("wss", "https", "mqtt"),
    )
    with ThalovantClient(result.identity, protocol="wss") as client:
    reply = client.ask("Tell me a short clean joke.")
    print(reply.text)

    Each SDK page explains the pieces: where the identity is kept, which protocols the hub accepts, what to pass as context, and how to listen for events.

    Start with the Pocket Quiz tutorial. You can write and test the whole thing on your own computer before you’ve a hub at all. It explains what each file is for and tells you what you should see after every step.

    When its checks pass, Add Your Own Skill puts it on a test hub. Then ask it a question out loud, try a follow-up, and check that “stop” ends the game.

    Writing a Skill is the reference you’ll reach for afterwards — helpers, conversation rules, tests, packaging. Keep Your Skill Responsive covers caching, bounded service calls, and background refresh.

    Thalovant creates the client identity and its access rule; your SDK uses that identity to connect straight to the hub.

    1. Choose a hub. A public hub is the easiest thing to test against.
    2. Create a client identity. This needs API access on the workspace.
    3. Install an SDK. Pick the language your app is already written in.
    4. Connect over WSS. It’s the default, and every SDK supports it.
    5. Add HTTPS or MQTT only if you need them. Python, Node.js, Go, and Rust support both once the hub enables them. Kotlin, Swift, and .NET are WSS-only; embedded C uses whatever transport your firmware already has.
    6. Ask for an SDK origin if you’re in a browser. A customer-owned domain needs review before cross-origin calls are accepted.
    7. Add context last. User, device, session, and trace metadata are worth adding once the first plain request works.

    Everything here goes through an SDK, and that’s on purpose. The SDKs are the supported surface: they handle the encrypted, authenticated session, the saved keys a reconnect needs, request correlation, and the retry and cancellation behaviour that a hand-rolled HTTP client has to get right on its own.

    There’s no published REST reference, so if you’re looking for one, this is why rather than an omission. Pick the SDK closest to your language — even embedded C, which brings its own transport and leaves the sockets to you.

    The MCP server exposes hubs to Claude, Codex, Cursor, and other agents as tools, so an agent can ask a hub something or manage skills without you writing a client.