Schedules, webhooks and multi-step flows share one declarative model with your database APIs. You're not bolting a second product onto a hand-rolled service, and you're not stuck in a canvas nobody can review in a pull request.
Cron and HTTP, the same interface
Any interface can run on a timezone-aware cron schedule instead of — or as well as — serving HTTP. Digests, polls and syncs are the same config as the endpoint next to them, with retries and backoff built in.
Timezone-aware cron, with retry and exponential backoff
The same interface can serve HTTP, a webhook and a schedule
Durable API Polling and Daily Database Digest Email packs show the shape
Branch, retry, delay, recover
Flow control is declarative. Gate a step on whether earlier ones succeeded, failed or merely finished; branch on an assertion; pace work with a delay action; and proceed once a quorum of sources come back rather than waiting on all of them.
run_on_assertion for branching, at_least for quorum
Throttle and pace with the delay action; try/catch/finally recovery
Cursors, dedupe and counters that survive
Durable key/value state means real automation rather than in-memory demos. Keep a polling cursor, an idempotency key or a seen-set between runs, and read it inline in the config.
get, set, advance and seen for cursors and dedupe
Read state inline as a|state::key|
Poll only what's new instead of reprocessing the batch
Reach the rest of your stack
Automation is only useful if it can touch things. Query your databases, call any HTTP API, run a command, send email over SMTP, and use Google and AWS cloud actions — then reshape what comes back with ordered transforms before the next step.
SMTP email, HTTP, commands, databases and cloud inputs
Ordered post_transforms — extract, filter, group and more
Assert on any result before it reaches the next step
Every scheduled run is traced
A nightly job that fails should tell you which step failed, not just show a red badge. Scheduled runs emit the same OpenTelemetry traces and Prometheus metrics as any request, so automation is as observable as the rest of your backend.
Frequently asked questions
Can an Air Pipe interface run on a schedule? Yes. Any interface can run on a timezone-aware cron schedule, with retries and exponential backoff, using the same config that defines your HTTP endpoints. Scheduling isn't a separate product or a separate price.
How does flow control work without a canvas? It's declarative. Steps gate on whether earlier ones succeeded, failed or finished; run_on_assertion branches on a condition; a delay action paces or throttles work; and at_least lets you proceed once a quorum of sources succeed rather than blocking on all of them.
Does state survive between runs? Yes. Durable key/value state — get, set, advance and seen — persists across runs, which is what makes polling cursors, idempotency keys and dedupe sets work. You read it inline in the config as a|state::key|.
Can automations send email? Yes, over SMTP with any relay, or through an HTTP provider such as Resend. It's an action like any other, so it's traced like any other.
How is this different from a workflow canvas? The artifact. A canvas produces a diagram; Air Pipe produces a config that is also a deployable service — with auth, OpenAPI docs, metrics and traces — that you can diff and review in a pull request. The automation and the API are the same thing.