Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.authforge.cc/llms.txt

Use this file to discover all available pages before exploring further.

The AuthForge SDK handles license validation, HWID fingerprinting, cryptographic signature verification, and background heartbeats.

​
Available SDKs

Python SDK

authforge-sdk on PyPIPython 3.9+; cryptography pulled in automatically.

C# SDK

AuthForge on NuGet.NET 6+ with BouncyCastle.Cryptography.

C++ SDK

CMake library from GitHubC++17, libsodium, OpenSSL, libcurl.

Rust SDK

authforge on crates.ioRust 1.70+, blocking HTTP via ureq.

Go SDK

github.com/AuthForgeCC/authforge-goGo 1.21+, standard library only.

Node.js SDK

@authforgecc/sdk on npmNode.js 18+, zero runtime dependencies.

​
Official installs

SDKInstall commandRegistry / source
Pythonpip install authforge-sdkPyPI; authforge-sdk
C#dotnet add package AuthForgeNuGet; AuthForge
Rustcargo add authforgecrates.io; authforge
Node.jsnpm install @authforgecc/sdknpm; @authforgecc/sdk
Gogo get github.com/AuthForgeCC/authforge-go@vX.Y.ZGitHub; authforge-go (module path; pin a release tag)
C++CMake: clone / release tarball, or FetchContent from GitHubGitHub; authforge-cpp (no C++ registry: build from source)

​
How it works

All SDKs implement the same flow:
  1. Initialize: Create a client with your App ID, App Secret, and heartbeat mode.
  2. Login or validate-only: Call login(licenseKey) (or Login, etc.) for a long-lived session: the SDK collects the machine’s HWID (or uses hwidOverride), generates a nonce, and sends /auth/validate. For bots, cron, or per-request checks, use the validate-only API (validateLicense in Node, validate_license in Python and Rust, ValidateLicense in C# / C++ / Go): same request and signature verification, no heartbeat and no persisted session on the client (C++ returns a result struct; others match their login result shape or a dedicated result type).
  3. Verify the validate response: The SDK verifies the Ed25519 signature on /auth/validate using your app’s configured publicKey.
  4. Heartbeat: After login, a background thread runs at the configured interval (default 15 minutes). /auth/heartbeat success responses are also Ed25519-signed and verified with the same app public key. Validate-only calls do not start this loop.
  5. Failure: If authentication or a heartbeat fails, the SDK calls your onFailure callback with a reason ("login_failed" or "heartbeat_failed") and the exception. If no callback is set, the process exits.

​
Common constructor parameters

Every SDK accepts the same conceptual parameters, named according to each language’s conventions. The table below shows the logical parameter names; see each SDK’s page for exact syntax.
ParameterTypeDefaultDescription
appIdstringrequiredYour application ID from the dashboard
appSecretstringrequiredYour application secret
publicKeystringrequiredYour app Ed25519 public key (base64)
heartbeatModestringrequired"SERVER" or "LOCAL"
heartbeatIntervalinteger900Seconds between heartbeat checks (any value ≥ 1 is supported)
apiBaseUrlstringhttps://auth.authforge.ccOverride the API base URL
onFailurecallbacknullCalled on auth/heartbeat failure with (reason, exception)
requestTimeoutinteger15HTTP request timeout in seconds
ttlSecondsintegernull / 0 (server default: 86400)Requested session token lifetime. Server clamps to [3600, 604800]. Preserved across heartbeat refreshes.

​
Billing model

All SDKs follow the same billing rules:
  • Each successful login() / Login() or validateLicense-style call costs 1 credit (one /auth/validate debit).
  • Heartbeats cost 1 credit per 10 successful calls (debited on every 10th heartbeat). Any heartbeatInterval ≥ 1s is economically safe.
  • Revocations take effect on the next heartbeat regardless of the configured interval.
See Managing Credits for usage estimates and cost-saving patterns.

​
Next steps