Skip to content

Create your first flag

In the next few minutes you’ll create a FortressFlag account, flip a real flag, and see the change land in the same API response your apps will read. No SDK install needed yet — just a terminal at the end.

Head to the dashboard’s signup page and create your organization. You’ll pick a name, set your email and password, and accept the service agreements — one checkbox, covering the bundle of documents linked right beside it.

That’s the whole form. Your trial starts immediately, includes 1,000 monthly-active devices, and never expires by time — evaluate at your own pace.

You land signed in as the organization’s Owner, and there’s already something to look at: an Example project with two environments — dev and production — and three boolean flags in believable states:

  • new-checkout — off everywhere, waiting for its rollout
  • dark-mode — on in dev, off in production
  • beta-banner — on in both

This is your sandbox. Everything you do in the rest of this page happens in the dev environment, where you can change anything freely.

Open the Example project, find new-checkout, and switch it on in dev. That’s a real change: it’s live for every device reading this environment, it’s in your audit log, and you’ll see it from the API in a moment.

(Try the same thing in production and you’ll notice the dashboard treats it differently — production-class environments get louder styling and stricter rules. That’s roles and safety at work.)

To read flags the way an app does, you need a client key. In the Example project, open SDK keys and mint one for the dev environment.

The full key — it starts with ffc_dev_ — is shown once, right now. Copy it. After this screen, the list shows only enough to identify it. (Lost it? Mint another and revoke the first — keys are cheap, and revoking is instant.)

Ask the client API for this device’s flags — the same request every SDK makes. Put the key you just copied in a variable, then:

Terminal window
export FF_SDK_KEY="(the ffc_dev_ key you just minted)"
curl -s "https://edge.fortressflag.com/v1/client/flags?environment=dev" \
-H "Authorization: Bearer $FF_SDK_KEY" \
-H "X-FF-Device: dev_8KqW3nR2vT7yLp0aZxQmBg" \
| jq -r .payload | tr '_-' '/+' | base64 -d | jq

(The response wraps its data in an encoded payload — the last three pipe stages unwrap it. The X-FF-Device header carries a device identity; SDKs mint their own, and for a terminal experiment any well-formed one works.)

You’ll get back exactly what a device in dev gets:

{
"v": 1,
"tenant": "…your organization's id…",
"environment": "dev",
"device": "dev_8KqW3nR2vT7yLp0aZxQmBg",
"issuedAt": "2026-08-23T15:00:00Z",
"expiresAt": "2026-08-23T15:30:00Z",
"flags": {
"new-checkout": true,
"dark-mode": true,
"beta-banner": true
}
}

There’s new-checkout: true — your toggle, served. Flip it back off in the dashboard, run the curl again, and watch it follow. That’s it — you’ve made your first flag change and read it from the data plane.