How to Capture Webhook Demo Bookings into Monday and Confirm by Email

Receive a demo-booking POST from your scheduling page, normalize the slot and contact, create the deal in Monday.com, confirm the prospect by email, and return a 200 to the caller while alerting the assigned rep in Slack.

What This Integration Does

When a prospect books a demo on your scheduling page, you want that booking to land in your CRM instantly, the prospect to get a branded confirmation, and the assigned rep to know it happened, all without anyone copying details by hand. This Spojit workflow listens for the booking as an HTTP POST, writes the deal straight into a Monday.com board with the meeting time, emails the prospect a confirmation from your own domain via Resend, and pings the rep in Slack. Because the scheduling page calls Spojit synchronously, the workflow also returns the created record id so the page can show a confirmation screen or store the reference.

The workflow is started by a Webhook trigger. Every POST to the workflow URL is verified by a signing connection, parsed into JSON, and made available as {{ input }}. A Transform node reshapes the raw payload into clean fields, a Condition node drops duplicate submissions, the monday create-item tool creates the deal, the resend send-email tool emails the prospect, the slack send-message tool alerts the rep, and a Response node returns a 200 with the new item id. Re-runs of the same booking are detected and short-circuited so the same prospect is not double-booked or emailed twice.

Prerequisites

A Monday.com connection (API key) and a board where demo deals live. Note the board id and the column ids you will write to (for example a date column and an email column).
A Resend connection with a verified sending domain, so confirmation emails come from your address rather than a generic one.
A Slack connection with permission to post to the channel your reps watch, plus the channel id.
A signing secret shared with your scheduling page so Spojit can verify each POST. You will configure this as a Custom signing connection on the webhook.
The exact JSON shape your scheduling page sends (prospect name, email, company, chosen slot, assigned rep). Keep one real sample payload handy for testing.

Step 1: Receive the booking with a Webhook trigger

Add a Trigger node and set its type to Webhook. Spojit gives you a unique workflow URL: paste that into your scheduling page's webhook setting. To verify each call, attach a signing connection and choose the Custom scheme, then enter the shared secret and the header your page signs with (for example X-Signature). Spojit checks the HMAC on every request and rejects anything that does not match, so only your scheduling page can start the workflow.

The trigger parses the POST body into JSON and exposes it as {{ input }}. A typical booking payload looks like this:

{
  "booking_id": "bk_8421",
  "name": "Dana Whitfield",
  "email": "dana@acme.io",
  "company": "Acme",
  "slot_start": "2026-07-02T15:00:00Z",
  "rep_email": "sam@yourco.com"
}

To protect against your scheduling page retrying a delivery, turn on dedup by setting the event-id header to the field that uniquely identifies a booking, such as booking_id. Spojit then ignores repeat deliveries carrying the same id.

Step 2: Normalize the slot and contact with a Transform node

Add a Transform node after the trigger to turn the raw payload into a tidy object the later steps can rely on. Trim and lowercase the email, build a friendly display time from {{ input.slot_start }}, and fall back to a default company when the field is missing. Output a clean shape such as:

{
  "bookingId": "{{ input.booking_id }}",
  "fullName": "{{ input.name }}",
  "email": "{{ input.email }}",
  "company": "{{ input.company }}",
  "slotStart": "{{ input.slot_start }}",
  "repEmail": "{{ input.rep_email }}"
}

If you need to reformat the timestamp into a reader-friendly string (for example the prospect's local date and time for the email body), add a Connector node in Direct mode on the date connector using format, and feed it {{ transform.slotStart }}. Keep the normalized object in a variable like booking so every downstream node reads one consistent source.

Step 3: Drop duplicate submissions with a Condition node

Even with header dedup, a prospect may submit twice from two browser tabs with different booking ids. Add a Condition node to decide whether this booking already exists in Monday.com before you create it. First add a Connector node in Direct mode on the monday connector using list-items against your deals board, then have the Condition node check whether any returned item already matches {{ booking.email }} and the same {{ booking.slotStart }}.

Wire the false branch (no existing match) into Step 4 so a new deal is created. Wire the true branch (already booked) straight to the Response node in Step 7 so the caller still gets a clean 200 and the existing record id, with no second deal, email, or Slack alert. This keeps repeat submissions idempotent.

Step 4: Create the deal in Monday.com with create-item

On the false branch, add a Connector node in Direct mode on the monday connector and pick the create-item tool. Map boardId to your deals board id, set name to a descriptive title such as Demo - {{ booking.company }} ({{ booking.fullName }}), and optionally set groupId to the group where new demos land.

Write the meeting time and contact into the board using columnValues, a JSON object keyed by your column ids. For example, mapping a date column and an email column:

{
  "date4": { "date": "2026-07-02", "time": "15:00:00" },
  "email_1": { "email": "{{ booking.email }}", "text": "{{ booking.email }}" },
  "text_company": "{{ booking.company }}"
}

Direct mode runs exactly this one tool with no AI cost. Save the result to a variable like deal so the new item id is available as {{ deal.id }} for the confirmation email, Slack alert, and Response node.

Step 5: Confirm the prospect by email with Resend

Add a Connector node in Direct mode on the resend connector and pick the send-email tool so the confirmation comes from your verified domain. Set the recipient to {{ booking.email }}, a from address on your verified domain, and a subject like Your demo with {{ booking.company }} is confirmed. Use the HTML body to brand the message and include the meeting time:

<p>Hi {{ booking.fullName }},</p>
<p>Your demo is confirmed for {{ booking.slotStart }}.</p>
<p>We look forward to speaking with you.</p>

If you do not have a verified sending domain yet, you can swap this step for a Send Email node, which sends from Spojit's built-in mail service with no connection. Resend is preferred here so the email carries your own brand and reply-to address. For a fuller walkthrough see the email notifications tutorial linked at the end.

Step 6: Alert the assigned rep in Slack

Add a Connector node in Direct mode on the slack connector and pick the send-message tool. Set the channel to your sales channel id and write a short message that links the rep to the new deal, for example:

New demo booked: {{ booking.fullName }} from {{ booking.company }}
Slot: {{ booking.slotStart }}
Owner: {{ booking.repEmail }}  -  Monday item {{ deal.id }}

If you want to tag the specific rep, add a Connector node in Direct mode on the slack connector first using lookup-user-by-email with {{ booking.repEmail }}, then include the returned user id in the message. Because Steps 5 and 6 do not depend on each other, you can place them in a Parallel node to run the email and Slack alert at the same time.

Step 7: Return a 200 to the scheduling page with a Response node

End the workflow with a Response node so the scheduling page that POSTed synchronously gets a real answer instead of just the trigger's acknowledgement. Set the status to 200 and return a small JSON body with the created record id so the page can show a confirmation screen or store the reference:

{
  "status": "confirmed",
  "mondayItemId": "{{ deal.id }}",
  "bookingId": "{{ booking.bookingId }}"
}

On the duplicate (true) branch from Step 3, route to a Response node that returns the same shape using the existing item's id, so a re-submission is indistinguishable to the caller from the first success. This makes the endpoint safe to retry.

Tips

Keep Monday.com column ids in the Transform node's output or in a small lookup object, so if a board column id changes you update one place, not every node.
Run the email and Slack steps inside a Parallel node to shave latency off the synchronous response your scheduling page is waiting on.
If a rep changes, a single Condition branch can route the Slack alert to a different channel based on {{ booking.repEmail }} without touching the rest of the flow.
Ask Miraxa, the intelligent layer across your automation, to scaffold this for you with a prompt like "Add a Condition node that checks if the booking email already exists in Monday and connect the false branch to a monday create-item node", then fine-tune the fields in the properties panel.

Common Pitfalls

Monday.com's columnValues shape is column-type specific: date columns expect a { "date", "time" } object and email columns expect { "email", "text" }. Sending a plain string into a typed column fails silently or rejects the mutation.
Resend will not send from an unverified domain. Verify your sending domain before going live, or temporarily use a Send Email node.
If the signing scheme or secret does not match what your scheduling page signs with, Spojit rejects every POST. Confirm the header name and the Custom secret match exactly.
Timezones bite here: slot_start usually arrives in UTC. Convert it to the prospect's local time for the email and to the board's expected format before writing the date column, or the meeting time will look wrong.

Testing

Before pointing your live scheduling page at the workflow, send one signed test POST with a sample payload to a throwaway board and a test prospect address you own. Confirm the deal appears in Monday.com with the correct meeting time, the confirmation email arrives from your domain, the rep alert lands in Slack, and the Response node returns a 200 with the new item id. Then submit the exact same payload again and verify the Condition node short-circuits: no second deal, no duplicate email, and the same item id returned. Once both paths behave, switch the board, channel, and from address to production values and enable the workflow.