Connect your CRM
Create and update contacts and appointment activities through workspace webhooks, Make, Zapier or your own receiver.
Use workspace webhooks with your own receiver or the Make/Zapier recipes. This also applies to Close: Calberry does not currently provide a native Close integration or an outcome back-sync.
Choose the business effects
Start with a small mapping:
| Calberry event | Suggested CRM effect |
|---|---|
lead.captured | Find/create a contact or store the inquiry; do not assume a booking exists. |
booking.created | Upsert an appointment activity using the Calberry booking ID. |
booking.rescheduled | Update that activity's time and status. |
booking.cancelled / booking.expired | Mark the activity cancelled/expired without deleting its history. |
lead.abandoned | Store the status; follow up only with the event's affirmative consent. |
lead.converted | Mark the inquiry converted; do not create another appointment if booking.created already did. |
booking.completed | Mark the scheduled period ended, without inventing attendance or a sale. |
These are integration choices, not additional Calberry events. Do not implement no-show or disqualification triggers from reserved event names.
Keep the identities separate
Use event_id for delivery/effect deduplication. Use data.lead.id to relate lead activity and data.booking.id to update the appointment. Add data.workspace_id to your keys if the integration serves several workspaces.
To match an existing CRM contact, normalize email in your own destination policy and restrict lookup to the correct account. Keep a mapping from Calberry IDs to CRM IDs. A new event must not create a duplicate deal just because the email already exists in another workspace.
Map only the needed data
Map available data.lead contact fields, selected data.answers, the appointment time/zone/status and useful data.attribution values. data.consent is a boolean snapshot for abandoned-lead follow-up; it is not general marketing consent. Omitted/null fields need an explicit destination policy rather than blindly erasing existing values.
The public payload excludes Meet and booking action links. If the integration needs current booking details, read them through the API with the necessary scopes using the generated reference.
Verify and recover
Verify the raw-body signature before parsing and business effects, exclude test events, and store accepted events durably. Use an atomic unique event key and per-effect completion records or idempotent destination upserts. A crash after a CRM write but before recording completion must not create duplicate activities on retry.
Do not assume all events arrive in order. Compare the event timestamp with the last applied state or reconcile current state through the API. See the limited ordering guarantee.
Test duplicate delivery, a reschedule, cancellation, a downstream failure and replay. Confirm that false consent never starts abandoned-lead messaging. Keep a separate error queue for accepted events that fail at the CRM.
Data responsibility
Calberry stores lead and booking data in the EU. Copies sent to your CRM follow that tool's storage locations and may leave the EU. Send only needed fields, restrict credentials/access and account for the destination in your privacy notices and retention process. Hiding a contact in Calberry does not erase a copy already sent to the CRM.