GET /flows
List flows the authenticated user owns (plus any public flows they’ve saved).string
required
Requires
flows:read scope (included in default key scopes).Response
array
GET /flows/:id
Fetch a single flow’s full FlowSchema plus a summary of the inputs it expects from API callers.string (uuid)
required
Response
string
required
string
required
string | null
object
required
The canonical FlowSchema. Nodes + edges, exactly as saved from the editor. See inline FlowSchema below for the shape.
array
Derived list of which steps expect a prompt or media input. Use this to drive your integration’s UI so users know what they need to supply.
Inline FlowSchema
Instead of saving a flow first, you can supply a complete FlowSchema JSON in theflow_schema body field of POST /runs. The worker topologically sorts nodes, validates every edge, and executes the graph — same pipeline as a saved flow.
When to use inline schemas
Programmatic flow generation
Your own app builds flows on the fly from templates, user settings, or AI.
Stateless integrations
You’d rather not manage flow state inside Hyperclip.
Per-user customization
Each end user gets a slightly different graph. Avoid mushrooming saved flows.
Ephemeral experiments
A/B test graph variations without cluttering the editor.
flow_id) remain the right choice when you want the flow discoverable in the Hyperclip UI, or when multiple integrations share the same graph.
FlowSchema shape
Minimal inline example
Inline schema caveats
- Max schema size: currently no explicit cap, but keep it under ~500 KB for reliable transport.
- Validation happens server-side: the worker runs the same Zod validation as the editor. Malformed schemas fail with
400 invalid_flow_schema. - No versioning: every inline schema must set
"version": 1. Future versions will add a migration path.
See also
Input reference
How to supply prompts, media, and per-step overrides at run time.
Node support matrix
Every node type supported by the API (all 26 — full parity with the editor).