Skip to content
feat.so feat.so

API keys

An API key is the SDK credential. Every key is scoped to one environment. feat has three key types, each with a different security posture and a different intended runtime.

The three key types

Section titled “The three key types”
TypePrefixSecret?Use it from
Serverfeat_sdk_…YesBackend code: Node.js, Go, Python, Ruby, any server runtime.
Mobilefeat_mob_…Treat as semi-secret.Mobile clients (iOS, Android).
Client-side IDfeat_cs_…No, safe to ship in a browser bundle.Browser JavaScript.

The prefix is also part of the token, so you can identify a leaked key by its first characters.

Server keys

Section titled “Server keys”

A server key has read access to the full datafile for its environment: every flag, every rule, every segment rule. Treat it like any other production secret. Store it in your secret manager; load it as an environment variable; never commit it; never ship it to a browser.

You can have multiple server keys active on the same environment. The intended pattern is rotate by addition: create a new key, redeploy services with the new key, revoke the old key once nothing is using it.

Mobile keys

Section titled “Mobile keys”

A mobile key has the same shape as a server key but is intended for distribution in a mobile app binary. Treat it as semi-secret: a determined attacker can extract it from an APK or IPA, but for most threats it is fine. Rotate by addition just like server keys.

Client-side ID

Section titled “Client-side ID”

The client-side ID is a public credential for browser JavaScript. It is safe to embed in your front-end bundle, paste into a HTML data attribute, or commit to a public repo.

Two properties make this safe:

  • The datafile served to client-side ID requests is filtered: only flags and segments that you have marked as available to client-side SDKs are included.
  • Every environment has exactly one client-side ID, fixed for the life of the environment. You cannot create more; you cannot revoke it. To “rotate” it you have to create a new environment.
  • Each client-side ID has an authorized URLs list. Requests with an Origin header not on the list are rejected. Add https://app.yourdomain.com and https://staging.yourdomain.com and so on.

If a client-side ID’s authorized URLs allow * or an attacker controls a listed origin, the protection drops to zero. Treat the list as a CORS allow-list.

Rotation

Section titled “Rotation”

For server and mobile keys, the workflow is:

  1. Create a new key on the environment.
  2. Roll out the new key to your services (deploy).
  3. Revoke the old key with an optional grace period (0, 15, 30, 60, 240, 720, or 1440 minutes). During the grace period the old key still works; after it the key returns 401.

The grace period exists so a misbehaving deploy can be unwound without locking yourself out. Use 60 minutes for a routine rotation; use 0 if you know a key has leaked.

You can also rotate every server key on an environment at once with a single action (“rotate all keys”), useful in incident response.

Where keys live

Section titled “Where keys live”

Open the dashboard, pick an environment, then API keys. The page shows:

  • A masked prefix and last-used timestamp for every key.
  • Buttons to create, revoke, and rotate.
  • The full token shown once at creation. Copy it then; you cannot recover it from the dashboard afterwards.
Section titled “Related”