FlowynBETA
LoginSign up
Execute

Run HTTP work reliably now or later.

Hand Flowyn an HTTP call. It is stored first, executed on managed workers, retried within a finite policy, and left with an attempt history you can read.

Start building Try it in the Playground
Job stored
test
POSThttps://api.example.com/reports/generate
Queued
job
job_8f29a
policy
5 attempts · exp. backoff
timeout
10,000 ms
idempotency
sync-invoice-881
Attempts · append-only
The call is persisted before any worker runs it. Nothing has been sent yet.
Problem

What teams build again and again

A fetch inside a request handler dies with the request. Teams then build queues, workers, leases, backoff, stale-worker recovery, and a cron that survives deploys. Every application, again.

What Flowyn provides

  • 01Durable HTTP jobs with method, URL, headers, body, and timeout
  • 02Finite retry policy with exponential backoff
  • 03Attempt history with status and duration
  • 04Cron schedules in a timezone; one-off jobs with run_at
  • 05Cancellation and explicit terminal status
Behavior

What exactly happens

At the product-contract level. This is what your application and your agent can rely on.

  1. 01

    Store

    POST /v1/jobs persists the call and returns HTTP 202 with a job id. Nothing has been sent yet.

  2. 02

    Attempt

    A worker claims the job and makes the request. A 5xx, 408, 429, timeout, or network error records a failed attempt.

  3. 03

    Retry

    Flowyn waits for the backoff interval and tries again until max_attempts. Attempts are never overwritten.

  4. 04

    Finish

    The job ends completed, failed, exhausted, or cancelled, with every attempt kept.

Statesqueuedrunningretryingcompletedfailedexhaustedcancelled
Capabilities

Everything around the execute operation.

POST /v1/jobs

Durable HTTP Jobs

Method, URL, headers, body, timeout, and attempt budget go in. A job with attempts and a terminal status comes out.

Explore POST /v1/schedules

Scheduled Jobs

A cron expression, a timezone, and an HTTP request. Each occurrence creates an ordinary job with its own attempts. Missed occurrences are skipped, not backfilled.

Explore
API example

One request. One resource you can read back.

Use an Idempotency-Key on durable create calls. Exact schemas are in the docs and OpenAPI.

For coding agents

An agent that needs to call a flaky third-party API creates a job instead of retrying in a loop. It receives a job id immediately and reads a single terminal status later. Schedules create the same jobs.

POSThttps://api.flowyn.dev/v1/jobs202
curl -X POST https://api.flowyn.dev/v1/jobs \
  -H "Authorization: Bearer flw_test_••••" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: sync-invoice-881" \
  -d '{
    "url": "https://api.example.com/reports/generate",
    "method": "POST",
    "timeout_ms": 10000,
    "max_attempts": 5
  }'

Also on Flowyn

Durable HTTP & schedules stays inside Flowyn's boundary: observe, verify, evaluate, execute bounded work, and report the result. The same account, API keys, and history cover every product.

Frequently asked questions

Is execution exactly once?
No. Execution is at-least-once. Send an Idempotency-Key on create; every outbound attempt carries Idempotency-Key set to the job id so the destination can deduplicate.
What happens to missed schedule occurrences?
They are skipped, not backfilled. Each occurrence that runs creates an ordinary job with its own attempts.
Can I cancel a job?
Yes, with POST /v1/jobs/{id}/cancel before it finishes. Attempts already made stay in history.

Start with durable http & schedules.

Create a workspace, make your first call in the test environment, and inspect every attempt.

Start building Read the docs