Everything the canvas does, over HTTP
Trigger workflows from your own systems, stream run events live, and approve paused steps — a typed REST API with an OpenAPI 3.1 spec and a real CLI.
The canvas builds the flow; your systems run it. Point a webhook at Arcflux or call the API directly — the same governed runs, triggered from code.
Inbound webhooks
- Give any system a URL: monitoring, forms, product events, CI.
- Webhook events pass the same policy gate as every other source — dedupe and noise-drop before a credit is spent.
- Plan-scoped endpoints: 2 on Basic, 20 on Starter.
The REST API
Eight operations, typed, OpenAPI 3.1: list and get workflows, create, list, get, and cancel runs, submit approvals, and stream run events.
- Trigger — POST /v1/runs starts a governed run with your payload.
- Stream — Server-Sent Events with cursor resumption — every step, token by token, as it executes.
- Approve — resolve paused approval steps programmatically.
- API keys are plan-scoped and masked Stripe-style in tooling.
The CLI
The arcflux CLI wraps the full run lifecycle: multi-profile auth, JSON output for jq pipelines, and exit codes that behave in CI.
arcflux run trigger <workflow> --input @event.json --wait arcflux run logs <run-id> arcflux run approve <run-id> --option approve
Common questions
The short version of how api & webhooks works. Anything else: info@arcflux.ai.
API keys (Bearer), created in the app — 1 on Basic, 5 on Starter.
Yes — an SSE stream with cursor-based resumption, the same feed Studio's live view uses.
No. Same policy gate, same approval pauses, same audit trail as every other trigger.
The OpenAPI 3.1 spec generates clients in any language, and the Go CLI ships today. TypeScript and Python SDKs are on the roadmap.
Turn your next event into a workflow
Model agentic workflows visually, trigger them from anywhere, and govern every run.