Docs/Libraries & CLI

Libraries & CLI

Three equivalent ways to talk to Wordcab. All share the same API shape and the same environment variables.

Three ways to call Wordcab. All three read the same environment variables and work against either cloud (api.wordcab.com) or your self-hosted control plane.

SDKs

Python

wordcab

pip install wordcab. 3.9+, typed, retries by default, sync and async.

 TypeScript

@wordcab/sdk

npm install @wordcab/sdk. Node 18+, Deno and Bun supported. Tree-shakeable ESM.

CLI

The wordcab CLI wraps the same API for scripts, CI, and operators. Ships as a single static binary for Linux, macOS, and Windows.

bash
brew install wordcab/tap/wordcab       # macOS / Linux
npm install -g @wordcab/cli           # any Node 18+ host
# or: download the static binary from the releases page

wordcab --version
wordcab login
wordcab transcribe call.wav --model qwen3-asr --diarize

Full reference: CLI overview and commands.

OpenAI SDK

If your stack already uses the OpenAI SDK, you can point it at Wordcab and keep your application code unchanged. Chat completions, embeddings, and audio endpoints are 1:1 compatible.

python
from openai import OpenAI

client = OpenAI(
    base_url="https://api.wordcab.com",
    api_key=os.environ["WORDCAB_API_KEY"],
)

See the compatibility guide for the supported surface, model-name mapping, and the two or three edges that differ.

Community clients

Self-hosted deployments: the SDKs work unchanged against on-prem, airgap, and VPC installs. Pass base_url (Python) or baseURL (TS) pointing at your control-plane ingress; keys issued by the self-hosted control plane are accepted the same as cloud keys. See self-hosted overview.

Community libraries for Go, Rust, Ruby, and Elixir exist at varying maturity. They are not first-party; check the wordcab-community GitHub organization before adopting. For anything production, prefer the official Python or TypeScript SDK or plain HTTP.