Install the SDK

A flags project has no snippet. Your application asks A vs B for flag values through an npm package, so this step happens in your codebase.

One command does all of this

npx @avsbhq/cli init detects your framework, writes the SDK key into the environment file that framework reads, writes a working example, and waits for your app's first check-in so you find out it worked from your terminal. See CLI Setup Command. The steps below are the same thing by hand, and are worth reading either way.

1. Install the package

For plain JavaScript or TypeScript:

Shell
npm install @avsbhq/browser
Shell1 line

For React:

Shell
npm install @avsbhq/react
Shell1 line
React needs one package, not two

The React package depends on the browser package and installs it for you, so there is no second install to run.

2. Put your SDK key somewhere your app can read it

Copy the key for the environment you are building against (use Development while you work) from the Environments page, and put it in an environment variable rather than a committed file:

Shell
# .env.localNEXT_PUBLIC_AVSB_SDK_KEY=sdk_development_your_real_key_here
Shell2 lines
Your SDK key is public
Your SDK key is a public identifier, not a secret: it is safe to ship in browser and mobile bundles, it can only fetch that environment's flag configuration and send events, and it can never read or change anything in your dashboard. Credentials covers all four A vs B credentials and which one to reach for.

Keeping the key in an environment variable is about swapping Development for Production without editing code, not about hiding it.

3. Initialise it once

Create the client once, as early in your application's life as you can, and let it finish loading before you read a flag. In React, the provider does the same job near the top of your tree.

import { AvsbClient } from '@avsbhq/browser'const client = new AvsbClient({  sdkKey: process.env.NEXT_PUBLIC_AVSB_SDK_KEY ?? '',  context: { kind: 'user', key: 'user_123', plan: 'pro' },})await client.onReady()
TypeScript8 lines

The context is who you are evaluating for. kind says what sort of thing it is, key is the identifier that bucketing hashes, and every other field is a targeting attribute your rules can read (plan, country, role). Leave context off entirely and the SDK keeps a stable anonymous visitor of its own, which is the right starting point before anyone signs in.

Built-in attributes still need your input

The dashboard suggests attributes like browser, country, and device type when you build a targeting rule, but the SDK never fills these in for you. If a rule uses one, add it to your context yourself, or that rule matches no one. Those same attributes (device, browser, platform, language, cookie, and URL parameter) also only work when the SDK runs in a real browser. Evaluate one on a server and nothing errors. The condition just never matches, so the rule silently excludes everyone.

Copy it with your key already in it

Open Environments, then View SDK setup instructions on the environment you want. The code there is the same as above with your real SDK key filled in, so there is no placeholder to replace.

  1. Press View SDK setup instructions on any environment card to open this dialog.
  2. Copy the code straight from here. Your real key is already in it.

4. Run your app, then check the dashboard

Start your application and let it load once. The SDK fetches its configuration and checks in with A vs B automatically. Nothing to call, nothing to configure.

Go to Environments. The environment you used now reads one of these:

What it saysWhat it means
ConnectedWe heard from an SDK in the last 5 minutes. You are done.
StaleWe heard from an SDK, but not recently. Normal for an app that is not running.
Not connectedWe have never heard from an SDK on this key.

The page updates itself while you watch, so a first connection appears without a refresh.

If it stays "Not connected"

Work down this list. It is ordered by how often each one is the answer.

  1. Wrong environment. Check whether the key in your app starts sdk_development_ or sdk_production_, and look at that environment's card, not the other one.
  2. The variable did not reach the code. Print the key your client is constructed with. An undefined environment variable is the most common cause, and it usually means the variable name is missing the prefix your framework needs to expose it to the browser.
  3. The app never initialised. The check-in happens after the configuration loads, so a client created in a code path that never runs never checks in.
  4. Blocked network. The SDK reads from cdn.avsb.cloud. If your app runs behind a strict proxy or a content-security policy, that host has to be allowed.

Going further

This page covers the shortest path that works. When you need bootstrapping for server-side rendering, polling intervals, change listeners, or a custom CDN host, the full reference is SDK Installation.

What happens next

The SDK is connected but has no flags to read yet. Continue to Your first feature flag.

Was this helpful?