Packages
Everything a client needs to talk to Prodantix ships as a package you install from your language own registry. Each is open source, versioned together, and speaks the same REST and realtime surfaces the rest of these manuals describe.
Which one you need
Pick by where the code runs, not by what you want to measure. Every client sends the same events, evaluates the same flags, and reads the same in-app inbox.
| Package | Registry | Where it runs |
|---|---|---|
| @prodantix/sdk | npm | Browsers, Node, and edge runtimes |
| prodantix_sdk | pub.dev | Flutter and Dart apps |
| prodantix-sdk | PyPI | Python backends |
| @prodantix/react | npm | React apps, over @prodantix/sdk |
| prodantix_sdk_flutter | pub.dev | Flutter apps, over prodantix_sdk |
Clients and adapters
Three clients do the work, and two adapters wrap one of them for a framework. An adapter adds no capability of its own: it owns the lifecycle its framework imposes, and hands you the client underneath.
Versions and parity
The packages are versioned together, so one version number means the same surface in every language. Method names match across clients, though a server client takes the user id on every call.
What they speak
Every client speaks REST. The TypeScript SDK also opens a websocket, which is what the messenger runs on. MCP is the server surface for external agents, and no client package speaks it.