How to Receive Calendly Webhooks Reliably

Calendly can notify your systems the moment someone books, reschedules, or cancels a meeting — via its invitee.created and invitee.canceled webhook events. The catch is the usual one: Calendly will happily POST those events to a URL, but you still have to stand up an endpoint that verifies the signature, handles retries when your service blips, and does something useful with the payload. This guide shows how to do all of that without writing or hosting a backend, using Bluejay Relay as the receiving layer.

What You'll Build

Calendly → Bluejay Relay (verify + transform + route) → your app, Slack, CRM, or spreadsheet.

Relay gives you a permanent, searchable log of every booking event, automatic retries, and one-click replay — so a bad deploy on your side never means a lost booking.

1. Create the Webhook Endpoint

In Bluejay Relay, create a new webhook and name it something like Calendly Bookings. You'll immediately get a unique capture URL:

https://in.bluejayrelay.com/api/webhooks/{your-token}

Every request Calendly sends here is logged with its full body the instant it arrives — before any processing — so nothing is ever silently dropped.

2. Register the URL with Calendly

Calendly webhook subscriptions are created through its Developer API (the webhook_subscriptions endpoint) or the developer console. Subscribe to the events you care about — commonly invitee.created and invitee.canceled — and set the subscription's URL to your Bluejay capture URL. When you create the subscription, Calendly returns a signing key; keep it for the next step.

3. Verify the Signature

Calendly signs each webhook with an HMAC-SHA256 signature sent in the Calendly-Webhook-Signature header, in a timestamped t=...,v1=... format. In Bluejay Relay, enable signature verification for this webhook and paste in the signing key. Relay checks the signature with a timing-safe comparison and rejects anything that doesn't match, so spoofed or replayed requests never reach your downstream systems.

Verification fails closed: if the signature is missing or wrong, the event is refused, not forwarded.

4. Transform the Payload

Calendly's payload is nested and verbose. With Relay's field mapping you can flatten it to exactly what your downstream expects — pull payload.invitee.email, payload.invitee.name, and the event start time into a clean, flat object, and drop everything you don't need. No code, and you can shape a different payload per destination.

5. Route It Anywhere

Add one or more destinations:

• Slack — post a "New booking: {{ name }} at {{ time }}" message to a channel.
• Your API — deliver a slim JSON body to your own endpoint.
• A spreadsheet or CRM — via their webhook/inbound endpoints.

One booking event can fan out to all of them at once, each with its own shape.

6. Retries and Replay Come Free

If a destination is down when a booking comes in, Relay retries with backoff and parks anything that still fails in a dead-letter queue. When your endpoint is healthy again, replay the missed events — individually or in bulk over a date range. You get the reliability of a proper queue without running one.

Why Not Just Point Calendly at Your Server?

You can — and then you own signature verification, retry logic, idempotency, a delivery log, and the pager when it breaks at 2am. For a single event type that might be fine. Once bookings feed real workflows, a dedicated receiving layer pays for itself the first time a deploy would otherwise have dropped a customer's meeting.

---

Set up your Calendly webhook free on Bluejay Relay — the free tier handles 10,000 events a month, no card required.