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.

Sidebar overview

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.

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:

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

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

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

Related

• Flow designer
• Getting started
• CLI reference