# Using the console

The FetchCatch **console** is where you manage tenants, design flows, connect APIs, and inspect runs. Access it after login at [fetchcatch.com/console](https://fetchcatch.com/console).

## Sidebar overview

| Section | Purpose |
|---------|---------|
| **Flows** | List, create, open designer, publish |
| **API sources** | Register OpenAPI specs |
| **Auth profiles** | Credentials for outbound API calls |
| **Response types** | Typed flow output schemas |
| **API keys** | Keys for `/v1/evaluate` |
| **Runs** | Execution history and debugging |

## Workspaces

If your tenant has multiple workspaces, switch via the workspace menu in the header. Each workspace has its own flows, sources, and runs.

The CLI binds to one workspace via `fcc init --workspace {slug}`. Keep console and CLI on the same workspace to avoid confusion.

### Settings → Workspaces

Each workspace has a **governance mode** that decides who can publish — console, CLI, or both —
and an **environment kind** label (`Development` / `Staging` / `Production` / `Other`) shown as
a chip on the workspace switcher and the flows list. Open **Settings → Workspaces → Settings**
to change either, and to record the git repo URL + branch that backs the workspace.

When the mode is `CodeManaged` the designer's Publish button is disabled and a banner explains
how to ship via CI. Full details: [governance.md](./governance.md).

## Flows list

Each row shows:

- **Name** and **slug** (slug is used in API URLs)
- **Draft / published** status
- Last updated time

A ribbon above the list shows the workspace's environment kind, governance mode, and
(if configured) the last git commit the CLI advertised. This is the at-a-glance "where am I
publishing to?" indicator.

Actions:

- **Open designer** — edit the draft graph
- **History** (from inside the designer) — opens a side panel with the per-version timeline:
  actor, source (`designer-publish` / `cli-publish` / `rollback` / …), and git commit
- **Publish** — snapshot draft as a callable version. Disabled when governance mode is
  `CodeManaged` (use `fcc publish` from CI instead)
- **Delete** (trash icon on each card) — permanently removes the flow from the workspace
  (draft, published versions, and sync history). Historical **runs** are kept for audit.
  `/v1/evaluate/{slug}` returns 404 after delete. Local `.fetchcatch/flows/*.json` is
  **not** removed until you run `fcc pull`.

## Auth profiles

Create profiles before wiring HTTP nodes:

| Profile type | Use when |
|--------------|----------|
| API key / Bearer | Static token header |
| OAuth 2.0 | Token refresh against your IdP |

Link a profile to an API source so all operations from that spec inherit auth. Choose a profile when adding a source, or open **API sources → {source}** and change the **Auth** dropdown on the detail page (changes save immediately). The sources list shows the linked profile on each card.

## Response types

Define the contract your flow returns:

1. Add properties with types and required flags
2. Set defaults where helpful
3. Bind the type on the flow's **start** node
4. Use **decision** nodes to set field values

## API keys

Keys authenticate **incoming** evaluate requests. They do not grant console access.

- Create keys per integration (e.g. `mobile-app`, `billing-service`)
- Rotate by creating a new key and deprecating the old one
- Never commit keys to git — use environment variables

→ [API keys](api-keys.md)

## Runs

Every evaluate call creates a run. The runs list shows status, flow, duration, and outcome. Click a run for:

- Step-by-step node execution
- HTTP request/response summaries
- Pause reason and resume instructions
- Errors with node id

→ [Runs & debugging](runs.md)

## Tips

- **Save often** in the designer — drafts are explicit, not auto-saved on every keystroke
- **Publish deliberately** — production callers use the latest published version
- **Use descriptions on nodes** — helps teammates and AI agents understand graphs later
- **Pull to git** before large refactors so you have a diff history

## CLI tokens (Settings)

For GitHub Actions or other CI, create a long-lived token under **Settings → CLI tokens**. Tokens are scoped to the **current workspace** — match the workspace slug in your repo's `.fetchcatch/project.json`.

Store the secret as `FETCHCATCH_TOKEN` in your CI provider. Do not commit tokens to git.

→ [Sync & CI](sync-and-ci.md)

## Related

- [Flow designer](flow-designer.md)
- [Getting started](getting-started.md)
- [CLI reference](cli-reference.md)