Environments

FetchPrompt provides two environments — Stage and Production — to give you a safe way to iterate on prompts before they reach your live application.

How environments work

Each prompt slug can exist independently in both environments. The Stage and Production versions of a prompt have:

• Separate content — You can edit Stage freely without affecting Production.
• Separate version histories — Each environment maintains its own version numbers and snapshots.
• Separate API keys — Stage keys (fp_stage_xxx) only return Stage prompts. Production keys (fp_prod_xxx) only return Production prompts.

This means the environment is determined entirely by which API key you use, not by a query parameter or header. This simplifies integration — your application code doesn't need to know about environments at all. You just configure the right API key per deployment.

Typical workflow

  ┌─────────────────────────────────────────────┐
  │  1. Create and iterate on Stage prompts     │
  │     using fp_stage_xxx key in development   │
  ├─────────────────────────────────────────────┤
  │  2. Test thoroughly with staging app        │
  ├─────────────────────────────────────────────┤
  │  3. Clone Stage → Production                │
  ├─────────────────────────────────────────────┤
  │  4. Production app fetches via fp_prod_xxx  │
  └─────────────────────────────────────────────┘

1. Develop in Stage — Write and iterate on prompts using the Stage environment. Your development/staging application uses a fp_stage_xxx API key.
2. Test — Verify the prompt works as expected in your staging environment.
3. Promote to Production — Use the Clone to Production button to push the Stage version to Production.
4. Serve in Production — Your live application uses a fp_prod_xxx API key and automatically gets the Production version.

Cloning Stage to Production

The Clone to Production button appears in the prompt editor when you're viewing a Stage prompt. Clicking it:

1. Copies the current Stage prompt content to the Production environment.
2. If a Production version of this prompt already exists, it increments the Production version and creates a new snapshot.
3. If a Production version doesn't exist yet, it creates a new Production prompt starting at version 1.
4. Records the action in the audit log with metadata about the source environment and version.

Cloning is one-way (Stage → Production). There is no Production → Stage flow. If you need to revert a Production prompt, use the version history and rollback feature.

Environment switcher

Throughout the dashboard, you'll see an environment switcher (Stage / Production tabs) that lets you toggle which environment's data you're viewing:

• Prompts list — Shows prompts for the selected environment.
• Prompt editor — Edits the prompt in the selected environment.
• Version history — Shows snapshots for the selected environment.

Configuring your application

The recommended approach is to use environment variables in your application to store the appropriate API key:

# .env.development
FETCHPROMPT_API_KEY=fp_stage_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

# .env.production
FETCHPROMPT_API_KEY=fp_prod_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Then your application code stays the same across all deployments:

const response = await fetch(
  `https://www.fetchprompt.com/api/v1/prompts/${slug}`,
  {
    headers: {
      Authorization: `Bearer ${process.env.FETCHPROMPT_API_KEY}`,
    },
  }
);

No code changes needed when switching environments — just swap the API key.