Webhook to MySQL: Capture-Then-Acknowledge Async Template

This Spojit template catches an incoming webhook, writes the raw payload to a MySQL table, replies to the caller right away, then keeps processing the event in the background.

What It Builds

A Webhook trigger receives an HTTP POST from an external system, an Insert Rows call on the mysql connector persists the raw payload into a capture table, and a Response node returns an immediate acknowledgement to the caller. After the response is sent, the remaining nodes run asynchronously to do the heavier work (validation, lookups, downstream calls) without making the sender wait. This is the decouple-and-defer pattern: capture first, acknowledge fast, then process at your own pace.

Because the payload lands in MySQL before any slow work begins, nothing is lost if a later step fails. You can reprocess from the stored row, and the caller never sees a timeout even when downstream processing is heavy.

The Prompt

Paste this into Miraxa, the intelligent layer across your automation, and it builds the workflow and connects the tools for you:

Build a workflow that starts with a Webhook trigger. First, use the mysql connector in Direct mode to insert the full incoming payload as a new row into a table called webhook_events, storing the raw JSON body and the received timestamp. Then add a Response node that immediately returns 202 with a JSON body containing a status of "accepted" and the inserted row id. After the Response node, continue processing the event asynchronously: parse the payload, run the downstream steps, and update the same MySQL row to mark it as processed when finished.

Connectors Used

Webhook trigger - an external system POSTs the event to the workflow URL, verified by a signing connection; the parsed JSON body is available as {{ input }}.
mysql - insert-rows persists the raw payload to your capture table, and update-rows marks the row processed once the async work completes.
Response node - returns the immediate 202 acknowledgement to the caller so processing can continue in the background.

Customize It

Change the table name (webhook_events) and the columns you store to match your schema, swap the acknowledgement body for whatever fields your caller expects, and decide what "processed" means by editing the final update-rows step. If the later work is reusable, point the async tail at a Subworkflow node instead so other workflows can share it.

Tips

Place the Response node right after the insert-rows call so the caller is acknowledged the instant the payload is safely stored, not after the slow work.
Use Direct mode on the mysql connector for both writes: the insert and the update are predictable single-tool calls, so you avoid AI cost and get deterministic behavior.
Store the raw body verbatim in one column (for example as JSON text) plus a status column you can flip later, so a failed downstream step never loses the original event.

Common Pitfalls

Without a signing connection on the trigger, anyone who learns the URL can write rows; configure a webhook signing connection so only trusted senders are accepted.
If you put the Response node after the heavy work, a slow downstream call can make the caller time out and retry, creating duplicate rows; capture and acknowledge first.
Reuse the inserted row id when you call update-rows at the end; updating by a loose match can touch the wrong row when events arrive close together.