Webhooks scheduling integration guide
Receive booking, response, cancellation, and finalization events. The intended connection would let product teams create, read, and react to scheduling state through stable authenticated interfaces.
PROVIDER SETUP GUIDE. Documented workflow, not a live Webhooks connection.Webhooks at a glance
| Category | API and connectors |
|---|---|
| Status | Provider setup guide |
| Job | Let product teams create, read, and react to scheduling state through stable authenticated interfaces |
| Data exchanged | Events, slots, participants, and lifecycle identifiers; signed webhook payloads and delivery timestamps; scoped credentials and request metadata |
| Related capability | Crm scheduling integration |
What the Webhooks connection is designed to do
For api and connectors workflows, the important job is to let product teams create, read, and react to scheduling state through stable authenticated interfaces. Receive booking, response, cancellation, and finalization events. It sits beside the other api and connectors connections and supports the CRM scheduling integration requirements.
Webhooks-specific integration decisions
Deliver signed, versioned events with object and delivery identifiers while supporting duplicates, delay, retries, replay, secret rotation, and state lookup.
Check these against current Webhooks documentation and your account edition; the verification standard explains how provider claims are reviewed.
Webhooks provider review points
- Deliver signed
- Versioned events with object
- Delivery identifiers while supporting duplicates
- Secret rotation
- State lookup
Scheduling data and actions in the workflow
For Webhooks, these are the data groups the connection exchanges. Record the source, destination, and owner of each before granting access:
- Events, slots, participants, and lifecycle identifiers
- Signed webhook payloads and delivery timestamps
- Scoped credentials and request metadata
Common Webhooks scheduling use cases
- Building scheduling inside another product
- Synchronizing a proprietary system
- Reacting to booking, response, finalization, and cancellation events
Webhooks setup and verification checklist
- Verify signatures before processing webhook data.
- Store delivery IDs and make consumers safe to retry.
- Use separate credentials and callback endpoints for test and production.
Availability, permissions, and limits
API and webhook availability is contract-specific. Consumers must handle rate limits, version changes, retries, and deleted records safely.
Retry and duplicate handling is covered in the API and webhook guide; ask about Webhooks to confirm production status before building on it.
Map the Webhooks workflow before connecting it.
Bring the trigger, required data, failure path, and desired guest outcome.
Discuss the connectionWebhooks integration questions
Provider-specific answers for teams planning a Webhooks scheduling connection.
Why did the same webhook arrive twice?
Delivery is at-least-once, so duplicates are expected. Make consumers idempotent on the event identifier — this is the single most important webhook design decision.
How do I verify a webhook is genuine?
Validate the signature against the raw request body before parsing. Middleware that reformats JSON is the usual cause of verification failures.
What should my endpoint return, and how fast?
A success status as soon as the event is safely stored, then process asynchronously. Slow endpoints get retried, and persistently slow ones get disabled.
Webhooks data and lifecycle decisions
1. Choose the identity model
A webhook delivers a signed, versioned event with an object ID and a delivery ID. The delivery ID is what a consumer stores to ignore repeats; the object ID is what it uses to look up current state.
2. Protect business ownership
The endpoint owner rotates the signing secret and monitors failures. A webhook that fails repeatedly should page someone, not disable itself silently.
3. Map the full lifecycle
Events cover confirmation, reschedule, and cancellation. Delivery can be delayed or duplicated, so consumers verify the signature, check the delivery ID, and then fetch current state rather than trusting the payload alone.
4. Keep traceable evidence
Keep delivery IDs for at least the retry window. Test a replayed delivery, an out-of-order pair, a secret rotation mid-stream, and an endpoint that times out.
