Build a workflow on a canvas, and let its steps call your APIs using secrets KnoxCall already holds in custody — injected at the moment of the call, never pasted into the automation, never visible in an export. Runs survive restarts, retry on your terms, and keep Live and Test completely apart.
Why it is different here
A workflow step references a Secret; it does not contain one. KnoxCall resolves and injects the value at call time, so the credential is not in the workflow definition, not in an export, and not in a screenshot of the canvas. It is the same custody path the API proxy uses — workflows are a consumer of it, not a second copy of it.
Steps name a Secret rather than carrying one. The fields a workflow persists are scanned for credential-shaped values before they are written, so a key pasted into a subject line or a header is refused rather than quietly stored in a definition anyone with edit access can read.
A workflow calling an arbitrary URL goes through the platform's resolve-and-pin egress path, the one that refuses private address space and KnoxCall's own hosts. An automation is not a way around the network controls the rest of the product enforces.
A workflow that sends email on the platform's mail credential may only use a From address at a domain you have proven control of in DNS. Sending on your own provider key is exempt — that is your provider enforcing its own rules.
Runs that outlive the process
Waiting is a state, not a held thread. A run that is waiting occupies no worker, and a deploy or a restart in the middle of it changes nothing about where it resumes.
Pause until a webhook arrives or an approver answers, then carry on with the run's full context intact.
A wait in the body of a loop suspends the run the same way a wait at the top level does, rather than holding a worker for the duration.
Factor shared logic into a sub-workflow and call it from several places. Nesting depth and fan-out are bounded, so a recursive mistake stops rather than multiplying.
When something breaks
Most automation tools tell you a run failed. The useful question is what happens next, and that is something you decide per step.
| Control | What it does |
|---|---|
| Per-step retry | Retry is decided per step, not per workflow, with a bounded number of attempts — so a flaky call can be retried without the whole run being replayed. |
| Status-aware HTTP retry | Switch it on for an HTTP Request step and it retries the statuses worth retrying — 429 and 5xx unless you name your own — honours the upstream's Retry-After, and caps how long that upstream can hold your step: 60 seconds by default, five minutes as a hard ceiling no configuration can raise. |
| Error branches | A step can have a second output that only failures take, drawn on the canvas like any other connection. |
| Error workflows | Point a whole workflow at another one that runs when it fails, so alerting and cleanup are themselves automation rather than a runbook. |
| Auto-disable after 5 | A workflow that fails five times in a row is disabled automatically, so a broken integration stops burning quota and filling logs instead of failing all week. |
Building one
The editor shows the shape of the run and the values flowing through it at the same time, so mapping a field does not mean guessing at its name.
After it runs
A finished run loads back onto the canvas it was drawn on — each step showing what it received and what it produced, in the place you are already looking.
Steps light up as the run progresses, streamed rather than polled, so a long run is watchable instead of opaque.
Fix the configuration and re-run from the failing step, keeping everything the run had already done rather than starting again.
Test runs use Test credentials and Test data, with no fallback to Live if something is missing. The mode is carried explicitly, not inferred.
What it talks to
Airtable, Anthropic, Discord, GitHub, GitLab, HubSpot, Jira, Linear, Notion, OpenAI, SendGrid, Shopify, Slack, Stripe, Telegram and Twilio — 88 operations and 17 triggers between them. Anything not on that list is an HTTP step, and an HTTP step can use a Secret exactly the way a connector does.