SDK Guides Overview
Liteguard SDKs are available for several languages and runtimes. Each SDK connects to the same Liteguard backend and evaluates guards against a locally cached bundle, so there is no network call per isOpen check regardless of language.
How all SDKs work
Every Liteguard SDK follows the same model:
- Initialize — create a client with your Project Client Token and call
start(). The client fetches the guard bundle for your project and environment from Liteguard and begins a background refresh cycle. - Evaluate — call
isOpen(guardName)anywhere in your code. The result is computed locally from the cached bundle. No network round-trip occurs. - Observe — the SDK buffers telemetry signals in the background and flushes them to Liteguard periodically. This powers the evaluation counts and last-seen timestamps visible in the guard catalog.
The bundle refresh and telemetry flush happen on their own timers and do not block your application's critical path.
Choosing a package
| Language / Runtime | Package |
|---|---|
| Node.js | @liteguard/liteguard-node |
| Browser / Edge | @liteguard/liteguard-browser |
| React | @liteguard/liteguard-react |
| Go | github.com/liteguard/liteguard |
| Python | liteguard (PyPI) |
| Ruby | liteguard (RubyGems) |
| Java | io.liteguard:liteguard (Maven) |
| Rust | liteguard (crates.io) |
All JavaScript and TypeScript runtimes are covered by the Node, Browser, and React packages. Use @liteguard/liteguard-node for any server-side Node.js or edge runtime, @liteguard/liteguard-browser for vanilla browser code, and @liteguard/liteguard-react for React applications. If you are unsure, start with the Node package; it includes TypeScript types and works in any CommonJS or ESM environment.
What you need before starting
Every SDK guide assumes you have:
- A Liteguard account with at least one workspace and project.
- A Project Client Token from the project detail page in Config.
If you do not have these yet, follow the Getting Started guide first.
Common patterns across all SDKs
Guard names
Guard names are strings your code passes to isOpen. They must match exactly what you create in the Liteguard web UI on the Guards tab. Guard names must start with an ASCII letter, may contain only ASCII letters, digits, ., -, _, and /, must be at least 3 characters long, and must not end with . or /. The match is case-sensitive. A common convention is dot-separated namespacing, for example payments.checkout or api/v2/new_endpoint.
Liteguard does not reject invalid names inside the client SDKs. The control plane enforces the contract server-side. In the TypeScript SDKs, string literals passed to guard APIs are checked at compile time.
Properties
Every isOpen call can include a properties map. Properties are key-value pairs that your guards' rules can match against. Values can be strings, numbers, or booleans. You only need to pass properties that are relevant to the rules you have defined.
Fallback behavior
If the SDK cannot load the bundle (for example, during a network outage), isOpen returns a fallback value. The default fallback is false. You can override this per call or globally in the client options.
Unadopted guards
Calling isOpen with a guard name that has no configuration in Liteguard returns false and records an unadopted guard observation. The next time you open the Guards tab, the guard will appear in the catalog under a separate section. Clicking Adopt lets you create a configuration for it without typing the name again.
Next steps
Pick the guide for your language and follow the installation and setup steps: