> ## Documentation Index
> Fetch the complete documentation index at: https://superflag.sh/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Keys, visibility, and evaluation

> Choose the correct credential and decide where feature flags are evaluated

# Keys, visibility, and evaluation

Superflag separates who may manage configuration from where configuration may
be delivered. Treat the prefix as a credential class, not as the complete
authorization check.

| Key      | Scope           | Use it for                                                               | Never expose it to                                                         |
| -------- | --------------- | ------------------------------------------------------------------------ | -------------------------------------------------------------------------- |
| `pub_`   | One environment | Browser, React Native, and Expo config delivery                          | N/A; it is a public identifier, but still has environment-scoped authority |
| `sdk_`   | One environment | Trusted server config, local server evaluation, remote evaluation, OFREP | Browser bundles, mobile apps, public env vars, logs, or responses          |
| `admin_` | One app         | Server-side management automation                                        | Client code or untrusted systems                                           |
| `cli_`   | One user        | CLI and user-owned management workflows                                  | Client code, repositories, or logs                                         |

## Server-only by default

Advanced flags and segments default to server visibility. A flag reaches a
client only when it has `visibility: "client"`. Every prerequisite and segment
referenced by that flag must also be client-visible. Invalid dependency graphs
fail closed instead of leaking a partial rule set.

Legacy flags use `clientEnabled: true`. The client delivery route never includes
legacy rules or overrides.

## Choose an evaluation model

| Model             | Best fit                                        | Tradeoff                                                             |
| ----------------- | ----------------------------------------------- | -------------------------------------------------------------------- |
| Client SDK        | UI flags and non-sensitive targeting rules      | Delivered rules and comparison values can be inspected by the client |
| Node SDK          | Trusted server, serverless, and edge code       | Syncs the full configuration and evaluates locally                   |
| Remote evaluation | Sensitive rules that should remain in Superflag | Adds a network round trip to each uncached decision                  |
| Core SDK          | You already possess a versioned config          | No transport or remote synchronization is included                   |

## Stable targeting identity

Percentage rollouts and experiments need a stable `targetingKey`. Use the same
logical subject for decisions that should remain in one cohort, such as a user,
organization, workspace, or install. Put additional allow-listed targeting data
under `attributes`.

```ts theme={null}
{
  targetingKey: organization.id,
  attributes: {
    plan: organization.plan,
    country: organization.country,
  },
}
```

The environment privacy allow-list removes attributes that were not explicitly
approved. Do not use random request IDs for a rollout that should remain stable.

## Fallbacks are part of the contract

Every typed value read has a deterministic fallback. Choose the fallback as the
safe product behavior when configuration is missing, invalid, unauthorized, or
too old to serve.

```ts theme={null}
await flags.isEnabled("new-checkout") // false fallback
await flags.getString("checkout-copy", "Continue")
await flags.getNumber("checkout-limit", 10)
```

<Note>
  Configuration sync pricing is per environment request, not per user. Both
  `200` and `304` config responses count as a sync; `304` avoids response bytes.
</Note>