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.
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:
npm install @avsbhq/browserFor React:
npm install @avsbhq/reactThe 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:
# .env.localNEXT_PUBLIC_AVSB_SDK_KEY=sdk_development_your_real_key_hereKeeping 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()import { AvsbProvider } from '@avsbhq/react'import type { ReactNode } from 'react'export function App({ children }: { children: ReactNode }) { return ( <AvsbProvider sdkKey={process.env.NEXT_PUBLIC_AVSB_SDK_KEY ?? ''} context={{ kind: 'user', key: 'user_123', plan: 'pro' }} > {children} </AvsbProvider> )}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.
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.
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.
- Press View SDK setup instructions on any environment card to open this dialog.
- 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 says | What it means |
|---|---|
| Connected | We heard from an SDK in the last 5 minutes. You are done. |
| Stale | We heard from an SDK, but not recently. Normal for an app that is not running. |
| Not connected | We 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.
- Wrong environment. Check whether the key in your app starts
sdk_development_orsdk_production_, and look at that environment's card, not the other one. - 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.
- 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.
- 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.