Hi everyone,
I’m Harry, the developer behind HookFlow. This post covers the engineering problem behind the app and how I solved the problem.
The two failure modes
A direct webhook integration into monday.com breaks in two places.
- Sender timeouts. Some senders give you about 5 seconds to reply. If your handler waits on the monday.com API, the sender marks the delivery as failed.
- HTTP 429 errors. The monday.com API enforces complexity, daily call, minute, concurrency and IP limits. A burst of requests hits one of them and the API rejects the call.
Some senders never retry a failed delivery. The payload is lost.
The design
I split the work into two steps. Accept first. Deliver second.
- Ingest. Each board gets a unique URL. HookFlow runs on Vercel’s edge layer and replies 200 OK in under 10ms. The sender never waits on monday.com.
- Pass-through. When monday.com accepts requests, HookFlow streams the payload to your board straight away. The payload stays in memory only.
- Buffer. When monday.com rejects the call, HookFlow encrypts the payload before queueing.
- Retry. A queue processor runs every 60 seconds and retries delivery.
- Delete. After a confirmed delivery, HookFlow hard-deletes the record. Undelivered records are purged after 7 days.
Field mapping
HookFlow maps JSON payload fields to board columns. The delivery step builds the item, so you do not write a mapping layer yourself.
Tradeoffs
- A buffered item arrives at the next retry, up to 60 seconds after monday.com recovers.
- Zero retention means HookFlow keeps no payload history after delivery.
- Undelivered payloads disappear after 7 days.
Questions for you
- How do you handle 429 errors today?
- Which senders fail on timeouts for you?
- What would you want from a delivery log?
Reply here or message me. I read every response.
Harry