Connect booking webhooks

1. Add your webhook receiver

A webhook sends an event from Schedivo to another service when a booking changes. Your workflow can use that event to create or update a CRM contact or appointment. This is outbound delivery; it does not provide a native CRM connection, a marketplace listing or changes flowing back into Schedivo.

1. In your automation tool, create a receiver and copy its HTTPS URL. The next section explains where to find it in Zapier, Make and n8n.
2. In Workspace settings → Webhooks, choose Add webhook. Enter a Name and paste the Endpoint URL.
3. Select one or more Booking events. Leave Include intake answers off unless the receiving service should have those answers. Leave Enabled on to send future matching events.
4. Choose Add webhook. Copy the one-time Signing secret into your receiver if you verify signatures yourself, then acknowledge that you have saved it. The secret cannot be shown again; you can rotate it.

2. Set up Zapier, Make or n8n

You need your own destination or automation account. Its plan and connector permissions determine which downstream actions are available. For a CRM workflow, find a contact by email and create it only if missing. Store the Schedivo booking ID on the appointment record so later changes update that record.

• Zapier: create a Zap with Webhooks by Zapier → Catch Hook, then copy its webhook URL. Read Zapier’s webhook instructions.
• Make: start a scenario with Webhooks → Custom webhook, create the webhook and copy its address. Read Make’s webhook instructions.
• n8n: add a Webhook node accepting POST. Use its temporary test URL while listening for a test, then save the published production URL in Schedivo for ongoing delivery. Read n8n’s Webhook node instructions.

3. Send a sample and check the result

1. Put your receiver into its listening or test mode, then choose Send sample beside an enabled webhook in Schedivo.
2. Choose one of its selected event types and confirm the sample. It contains fictional booking details with test: true and creates no booking.
3. Inspect the received fields and map them to your workflow’s next action. Use a test CRM/contact while setting up actions that create records or send messages.
4. Choose Deliveries beside the webhook and refresh its history to see the result. Check your automation tool’s execution history for the later CRM actions.

Choose the booking events to send

Attendance is staff-recorded. Reaching the scheduled end time does not emit a completion event. Rescheduling resets attendance inside Schedivo but emits only the reschedule event. Events are captured with the committed booking change. Existing bookings are not backfilled when you add or resume a webhook.

• booking.confirmed — a booking becomes confirmed. Pending and failed requests do not emit this event.
• booking.rescheduled — a confirmed booking commits changed start/end times. Guest-only changes do not emit it.
• booking.cancelled — a confirmed booking commits cancellation, including cancellation before deletion.
• booking.attendance_recorded — staff change attendance after a booking ends, including correcting it or resetting it to unknown.

Understand the booking payload

Each POST has Content-Type: application/json and schemaVersion: 1. The example below uses illustrative IDs. Treat actual IDs as opaque strings, rather than expecting a particular UUID format. The top-level id identifies the event; data.id identifies the booking.

• generation increases with booking changes. Attendance has its own increasing attendanceVersion. Attendance values are unknown, attended or no_show.
• With intake enabled, data.intakeAnswers is an array of objects containing questionId, label and value. Otherwise that field is absent.
• Only the primary booker’s name/email is exported. Additional guests, private host notes, transcripts, AI drafts, calendar credentials, joining links and booking management links are excluded.

{
  "id": "evt_example_booking_confirmed_1",
  "type": "booking.confirmed",
  "schemaVersion": 1,
  "createdAt": "2026-11-09T10:00:00.000Z",
  "workspaceId": "example-workspace",
  "test": false,
  "data": {
    "id": "example-booking",
    "generation": 1,
    "status": "confirmed",
    "meetingType": { "id": "example-type", "name": "Discovery call" },
    "start": "2026-11-12T10:00:00.000Z",
    "end": "2026-11-12T10:30:00.000Z",
    "timezone": "Europe/London",
    "client": { "name": "Example client", "email": "[email protected]" },
    "host": { "id": "example-host", "name": "Example host", "email": "[email protected]" },
    "attendance": "unknown",
    "attendanceVersion": 0
  }
}

Verify signatures on your own server

For your own receiver, verify the signature before processing the event. Use the entire signing secret, including whsec_, as the UTF-8 HMAC key. Sign <timestamp>.<exact raw request body> with HMAC-SHA256 and compare the hex digest in constant time. Read raw bytes before parsing JSON; reserialising JSON changes the signed representation.

• X-Schedivo-Event-Id is the stable event ID, also present in the JSON body.
• X-Schedivo-Delivery-Id is the delivery ID, stable for automatic and manual retries.
• X-Schedivo-Signature has the form t=<Unix seconds>,v1=<hex HMAC-SHA256>. Check its timestamp against your clock, for example within a five-minute tolerance.

import { createHmac, timingSafeEqual } from 'node:crypto';

export function verifyWebhook(rawBody, signatureHeader, secret, now = Date.now()) {
  const match = /^t=(\d+),v1=([a-f0-9]{64})$/.exec(signatureHeader || '');
  if (!match) return false;
  const timestamp = Number(match[1]);
  if (!Number.isSafeInteger(timestamp) || Math.abs(now / 1000 - timestamp) > 300) return false;
  const expected = createHmac('sha256', secret)
    .update(`${timestamp}.`, 'utf8').update(rawBody).digest();
  const supplied = Buffer.from(match[2], 'hex');
  return supplied.length === expected.length && timingSafeEqual(supplied, expected);
}

Handle duplicate and delayed events

Delivery is at least once. A receiver can accept a request while Schedivo loses the response, so duplicates are possible. Make actions idempotent using the stable event ID and booking ID. Retries preserve the exact payload and event ID; each attempt receives a fresh signing timestamp.

Delivery order is not guaranteed. Ignore older booking generations, then compare attendance versions within a generation, so a delayed confirmation cannot overwrite a newer cancellation.

Check history and retry failed deliveries

Open Deliveries beside a webhook. History shows the event, queued/created time, status, total attempt count, latest HTTP status/error, delivery time and next scheduled attempt where applicable. Receiver response bodies and raw request payloads are not exposed in history.

• Network errors, HTTP 408/425/429 and 5xx responses receive up to six automatic attempts. Earliest retry delays are 30 seconds, two minutes, ten minutes, one hour and six hours. Background recovery runs every five minutes, so these are earliest times rather than delivery guarantees. Initial attempts stop after 24 hours.
• Other non-2xx responses and redirects fail without automatic retries. Private or otherwise rejected destinations are not contacted.
• Choose Retry delivery for an eligible failed delivery. Owners can retry it at most three times within its seven-day retention window, while the endpoint is enabled and unchanged. Each manual retry starts a fresh bounded attempt cycle and 24-hour deadline; the original seven-day retention cutoff still applies.
• Samples are limited to five per workspace per minute. Other webhook management actions are limited to twenty per minute.

Edit, pause, rotate or delete a webhook

Choose Edit to change the URL, selected events, intake permission or enabled state. Save or discard edits before using the maintenance actions. Pause webhook stops future events; Resume webhook enables future events without backfilling missed ones.

• Saving any endpoint change, pausing it or rotating its signing secret cancels outstanding and failed deliveries from the previous endpoint version and clears their payloads. Already-started requests may finish.
• Rotate signing secret takes effect immediately, without an overlap period. Copy the new one-time secret and update your receiver before sending another sample or processing new bookings.
• Delete webhook removes the destination, credentials and delivery history. Review its confirmation before deleting.

Understand privacy and retention

Destination URLs and signing secrets are encrypted. Queued/failed payload snapshots are kept within a seven-day retention window so retries use the original content. Successful deliveries have their stored payload cleared immediately. Endpoint changes clear cancelled payloads; scheduled cleanup removes delivery history after seven days.

Closing a workspace cancels queued work. Deleting it removes its webhook records. An event already sent to another tool remains subject to that tool’s storage and deletion controls. Audit entries contain action/resource IDs, rather than URLs, secrets or payloads.