$ sdks
SDKs in six languages.
Drop-in clients for the languages most people writing desktop software
actually use. Each SDK ships an AGENTS.md in the repo for AI
coding tools, integration tests, an example app, and a stable public API
versioned with semver.
| Language | Install | Runtime | Links |
|---|---|---|---|
| Python | pip install authforge-sdk | Python 3.9+ | docs · repo |
| Node.js | npm install @authforgecc/sdk | Node 18+ (TypeScript types included) | docs · repo |
| Go | go get github.com/AuthForgeCC/authforge-go | Go 1.21+ | docs · repo |
| Rust | cargo add authforge | Rust 1.70+ | docs · repo |
| C# | dotnet add package AuthForge | .NET 6.0+ | docs · repo |
| C++ | cmake-fetched header + libsodium | C++17 | docs · repo |
Two integration patterns
Every SDK supports both modes. Pick whichever matches your app's runtime model. You can mix them across products on the same account; the credit pool doesn't care.
Stateful: login + heartbeat
App calls validate_license() on launch (1 credit), then
calls heartbeat() on a recurring interval (typically
every 5–15 minutes) to keep the session alive.
Best for: long-running desktop apps, productivity tools, games, or anything where session-level concurrent-use enforcement matters. Heartbeats bill at 10:1, so the marginal cost is small.
Stateless: one-shot validate
App calls validate_license() once per launch (or once
per privileged operation) and skips heartbeats entirely.
Best for: short-lived CLI tools, command-line utilities, scripts that run once-per-invocation, or any flow where there's no long-lived session to monitor.
SDK we don't have? Build your own.
The wire protocol is documented in full at docs.authforge.cc/api/runtime . You need an HTTPS client and an Ed25519 verify primitive; almost every modern stdlib has both. The signed validation page has verification snippets you can lift directly.