Skip to main content

SDKs Overview

Learn with runnable samples​

Start with the Toggly.Samples catalog. Each available sample includes setup, a first-toggle exercise, source files to read, and tests. Choose an available example that matches your framework and follow its README.

A flag key identifies a decision; its environment selects the definitions to load. Start with local defaults, observe both the enabled and disabled paths, then follow the sample's separate dashboard provisioning steps. Offline fixture results do not prove live connectivity.

Toggly provides SDKs for multiple platforms and languages. All SDKs share common concepts and patterns.

Available SDKs​

  • JavaScript: JavaScript and frontend framework SDKs (Vanilla JS, React, Angular, Vue.js, Svelte)
  • Blazor: SSR, Interactive Server, WebAssembly and Auto
  • NestJS: HTTP modules, request-scoped services and feature guards
  • .NET: .NET and .NET Core applications
  • Elixir / Phoenix / LiveView: Supervised local evaluation and request/socket context
  • Go: Go server-side SDK (local evaluation)
  • PHP: PHP applications with Laravel and WordPress support
  • Java: Java applications
  • Python: Python applications
  • Node.js: Node.js server-side applications
  • Rust: Rust applications
  • Ruby / Rails: Ruby and Ruby on Rails applications
  • Flutter: Flutter applications
  • CSS / HTML: Show or hide HTML with a generated stylesheet (no JavaScript)
  • iOS (Swift): Native iOS, macOS, tvOS, and watchOS applications
  • Android (Kotlin): Native Android applications with Jetpack Compose and Views support
  • React Native: React Native and Expo applications
  • Electron: Electron desktop applications (main + renderer)
  • Next.js: Next.js 14+ App Router with Server, Client, and Edge support
  • React Router: React Router 7/8 framework mode with full SSR support
  • Remix (deprecated): migrate to the React Router SDK
  • Nuxt: Nuxt 3 and Nuxt 4 applications with SSR/SSG and auto-imported composables
  • Docusaurus: Docusaurus plugin for documentation gating
  • Astro: Astro integration with SSR/SSG support and framework wrappers
  • Gatsby: Gatsby applications with SSR/SSG and build-time page gating
  • WordPress: WordPress plugin (settings, shortcodes, toggly_is_enabled, WP-Cron)

CLI Tool​

The Toggly CLI is a powerful command-line tool for automating Toggly operations. Perfect for CI/CD pipelines, it enables you to:

  • Create and manage releases
  • Associate CI builds with releases
  • Create and update feature flags
  • Update feature configurations across environments
  • Integrate seamlessly with GitHub Actions, Azure DevOps, and other CI/CD platforms

👉 Get started with the CLI →

Hooks​

JavaScript SDKs can register lifecycle callbacks for analytics (Clarity, GA4, Application Insights) and custom integrations. Hooks are documented here; they are not a create-app Technology Stack.

👉 Hooks documentation →

Common Concepts​

Initialization​

All SDKs require initialization with your App Key:

// Example: JavaScript
Toggly.init({
  appKey: 'your-app-key',
  environment: 'production'
});

Feature Evaluation​

Evaluate feature flags:

// Boolean evaluation
if (Toggly.isFeatureOn('my-feature')) {
  // Feature is enabled
}

User Context​

Provide user context for targeting and rollouts:

Toggly.init({
  appKey: 'your-app-key',
  environment: 'production',
  userIdentifier: 'user-123'
});

Caching​

SDKs cache feature flags to reduce API calls:

  • Cache Duration: Configurable cache TTL (default: 3 minutes for definitions, 30 minutes for user sessions)
  • Cache Invalidation: Automatic on updates
  • Offline Support: Use cached values when offline

Device-local master switches can further gate cached remote booleans at read time — see Post-filter gates. Live updates use WebSocket sync with a shared definitions revision.

Error Handling​

SDKs handle errors gracefully:

  • Network Errors: Fall back to cached values or defaults
  • Invalid Responses: Fall back to default values
  • Flag Defaults: Set default values for offline scenarios

Best Practices​

1. Use Environment Variables​

Store App Keys in environment variables or configuration:

TOGGLY_APP_KEY=your-app-key
TOGGLY_ENVIRONMENT=production

2. Initialize Once​

Initialize the SDK once and reuse the instance:

// Good: Initialize once
Toggly.init({...});

// Bad: Initialize multiple times
Toggly.init({...});
Toggly.init({...}); // Don't do this

3. Handle Errors​

Always handle errors and provide defaults:

// Set flag defaults for offline scenarios
Toggly.init({
  appKey: 'your-app-key',
  environment: 'production',
  flagDefaults: {
    'my-feature': false // Default to disabled if offline
  }
});

4. Use Caching​

Feature definitions are automatically cached and refreshed periodically.

5. Provide User Context​

Include user identifiers for accurate targeting and consistent rollouts:

Toggly.init({
  appKey: 'your-app-key',
  environment: 'production',
  userIdentifier: 'unique-user-id'
});

Cheat Sheets​

Looking for a quick reference? Every SDK ships with a printable two-page cheat sheet covering install, init, evaluation, framework integrations, and common pitfalls.

Next Steps​

Choose your platform and follow the specific SDK guide: