API keys

API keys authenticate requests to the Evaluate API (/v1/evaluate, /v1/runs/.../resume). They are separate from console login and CLI credentials.

Creating a key

Console → API keys
Click Create
Name the key (e.g. production-billing, staging-mobile)
Copy the secret immediately — it is shown once

Store the secret in your secrets manager or environment variables:

FETCHCATCH_API_KEY=fc_live_...

Using a key

curl -X POST "https://api.fetchcatch.com/v1/evaluate/my-flow" \
  -H "Authorization: Bearer fc_live_..." \
  -H "Content-Type: application/json" \
  -d '{"userId": "123"}'

FetchCatch expects the raw key in the Authorization: Bearer header.

Scope

Keys are tenant-scoped. They can evaluate any published flow in any workspace belonging to the tenant unless future fine-grained scopes are added — treat keys as powerful secrets.

Rotation

Create a new key
Deploy the new secret to your services
Revoke or delete the old key in the console

No downtime if you overlap keys during migration.

CLI vs API keys

Credential	Used for
Console login / `fcc login`	Designer, sync (`fcc pull/apply`)
API key	`/v1/evaluate` from your apps

Do not use API keys with the CLI sync commands.

Sync metadata (pull-only)

fcc pull writes api-keys/{slug}.json files containing metadata (id, name, timestamps) — not the secret value. These files are pull-only: create or revoke keys in the console, then run fcc pull. Do not add local api-keys/*.json files and expect fcc apply to create keys on the server.

→ Sync & CI

CI secrets

For GitHub Actions syncing flows, use a CLI token from Settings → CLI tokens:

FETCHCATCH_TOKEN — recommended (long-lived, workspace-scoped)

Or console credentials (legacy):

FETCHCATCH_CONSOLE_EMAIL + FETCHCATCH_CONSOLE_PASSWORD

Not API keys.