Environments and Release

A version doesn't reach production by being saved. It moves through environments by explicit release — independently of when your code deploys.

This page covers: the lifecycle, the release model, what the SDK enforces, and the 409 contract you'll hit when there's a mismatch.

The lifecycle

save  →  development  →  testing  →  production
  │          │              │            │
draft     dev fetches    QA fetches  customers
          succeed        succeed     fetch succeed

• Save — version exists in history. No environment fetches it.
• Release to development — your dev/local fetches with environment="development" now return this version.
• Release to testing — same for CI / staging.
• Release to production — customers see it.

A version can be released to any subset of environments. Multi-env release is normal: a version vetted in dev and testing is typically promoted to production while remaining released in the earlier envs (so dev fetches keep returning the same content).

Active version vs released environments

These are two separate concepts, and confusing them is the most common point of friction. Pin them down:

• Active version — which version a prompt is currently serving. There's exactly one active version per prompt at a time. Set in the UI.
• Released environments — who can fetch a given version. Each version has its own list. Set per-version.

The SDK call combines both:

"Fetch the active version of this prompt, but only if it has been released to my environment."

If the active version isn't released to your environment, you get a 409 — not the old version that was released. This is deliberate: silently serving stale content because the new one isn't ready is worse than failing loudly.

Release model in detail

A typical promotion sequence:

day 1   v1.0 saved                       envs: []                            active: none
day 1   v1.0 → set active                envs: []                            active: v1.0
        ↑ still not fetchable - no env

day 1   v1.0 → released to development   envs: [development]                 active: v1.0
        ↑ now dev fetches return v1.0

day 2   v1.1 saved                       envs: []                            active: v1.0
        ↑ draft; dev fetches still get v1.0 (the active version)

day 2   v1.1 → set active                envs: []                            active: v1.1
        ↑ dev fetches now FAIL with 409 - v1.1 is active but not released anywhere

day 2   v1.1 → released to development   envs: [development]                 active: v1.1
        ↑ dev fetches return v1.1

day 5   v1.1 → released to testing       envs: [development, testing]        active: v1.1
day 8   v1.1 → released to production    envs: [development, testing, prod]  active: v1.1
        ↑ customers see v1.1

Note the day-2 step where v1.1 is set active but not released — that's a real, common failure mode if you set "active" before "released." Either release first, then set active, or do them atomically in the UI ("publish to development" usually combines both).