FlowynBETA
LoginSign up
Connect

Deliver events without building webhook infrastructure.

POST an event. Flowyn stores it, signs the delivery, retries when the receiver is down, keeps every attempt, and lets you replay it later.

Start building Try it in the Playground
Event stored · 202
test
order.completed
evt_8e12c · signed · idempotency order-123
Stored
https://hooks.example.com/orders
Delivery attempts
Persisted before any endpoint is called. Your request already returned HTTP 202.
Problem

What teams build again and again

Webhooks look like one HTTP call until the receiver is down at 3 a.m. Then you need signing, backoff, attempt logs, a replay tool, and a way to notice that the same destination has been failing for hours.

What Flowyn provides

  • 01Events stored before any delivery is attempted
  • 02Signed HTTPS deliveries in the Standard Webhooks format
  • 03Up to 8 attempts per delivery, each recorded
  • 04Manual replay with history kept
  • 05Endpoints with signing secrets and test deliveries
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/events persists the event and returns HTTP 202. Your request is done.

  2. 02

    Deliver

    Flowyn signs and POSTs the payload to each enabled endpoint subscribed to the event type and records the response.

  3. 03

    Retry

    A failed attempt schedules the next one, from seconds to hours apart, within the policy.

  4. 04

    Read or replay

    Delivery succeeds on a 2xx. The attempt history stays attached to the event. Repeated failures also surface as an Issue.

Statesaccepteddeliveringdeliveredfailedcancelled
Capabilities

Everything around the connect operation.

POST /v1/events

Webhook Delivery

An event type and a JSON payload go in. A stored event and signed delivery attempts to every subscribed endpoint come out.

Explore Delivery retry policy

Webhook Retries

A stored event and an enabled endpoint go in. Up to 8 delivery attempts come out, from seconds to hours apart, each with status, duration, and timestamp.

Explore POST /v1/events/{id}/replay

Event Replay

A stored event goes in. A new delivery comes out, freshly signed, while the original attempts stay in history.

Explore POST /v1/endpoints/{id}/test

Integrations

A configured HTTPS destination goes in. A test delivery with its recorded result comes out. The signing secret is shown only once, at creation.

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

Instead of writing a delivery loop, an agent emits events with POST /v1/events and reads delivery facts with GET /v1/events/{id}/attempts. Status codes and timestamps are explicit fields.

POSThttps://api.flowyn.dev/v1/events202
curl -X POST https://api.flowyn.dev/v1/events \
  -H "Authorization: Bearer flw_test_••••" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-123-completed" \
  -d '{
    "type": "order.completed",
    "payload": {
      "order_id": "ord_123",
      "total": 4900
    }
  }'

Also on Flowyn

Reliable events & webhooks 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 delivery exactly once?
No. Delivery is at-least-once. Receivers should deduplicate on the webhook-id header, which is the event id and stays the same across retries.
What does replay do?
Replay sends the same event again as a new delivery. The original attempts remain in history.
How are deliveries signed?
In the Standard Webhooks format: webhook-id, webhook-timestamp, and webhook-signature headers, with an HMAC-SHA256 signature keyed by the endpoint's whsec_ secret. The secret is shown once.

Start with reliable events & webhooks.

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

Start building Read the docs