Corsair Workflows is in beta. The authoring surface is still growing; the trigger and execution APIs below are stable.
The model
A workflow moves through three places:1
Author in Hub
Workflows are authored and managed in Hub, which handles the scheduling and durable orchestration. From your app you run and inspect them through
corsair.workflows. Call corsair.workflows.run(id, { payload }), .list(), or .get(id). These need hub configured on createCorsair.2
Trigger
A run starts one of three ways: manually from your app (
corsair.workflows.run(id)), from an incoming webhook, or on a schedule (cron/cadence) configured in Hub.3
Execute in your app
Your app runs the delivered workflow in a locked-down sandbox, against a tenant-scoped
corsair client. Because it executes where your integrations and credentials already live, a workflow can call any plugin you’ve connected, and Hub never sees a token.Why built-in
- No engine to wire. No external durable-execution service to run, secure, and pay for. Workflows run in the app you already deploy.
- Runs where your data is. A workflow uses the same tenant-scoped client as the rest of your code, so it calls
corsair.slack.api.*,corsair.github.api.*, and friends directly. - Durable by default. Steps are memoized and sleeps are durable, so a run resumes exactly where it left off after a retry or a scheduled pause, and you don’t build the bookkeeping.
What’s next
Triggering
Start and list runs from the
corsair.workflows client, with manual, webhook, and schedule triggers.Execution & steps
Turn on execution, and how
step() and step.sleep() make a run durable.Workflow engines
Prefer an external engine? Corsair also drives Inngest, Temporal, Trigger.dev, and Hatchet.
Triggers
How incoming webhooks reach your app and can start a workflow.