Integrations and webhooks

Integrations send business events to another service the moment they happen: a new conversation, a booking, a request for a team member, a support request. With Zapier or Make you can, for example, add a row to a spreadsheet, send a message to a chat or create a CRM record without copying data by hand.

Where to find it

Open “Modules” in the top menu, connect the “Integrations” module (it is off by default) and click “Open integrations” on its card. The “Webhooks” tab opens, with the “Event log” tab next to it. Only the Owner and the Administrator can open the section: the receiver address can contain a private token. While the module is off nothing is delivered, and events that happen in the meantime are not resent later. Receivers stay configured and the event log keeps recording.

How to add a receiver

1. In Zapier create a Zap with the “Webhooks by Zapier” trigger and the “Catch Hook” event, and copy the address it gives you. In Make add the “Custom webhook” module and copy its address.
2. On the integrations page fill in “Name” (for example, the name of the Zap) and “Receiver address” (the copied address).
3. In “Events to send” tick what to send.
4. Click “Add receiver”.
5. The signing secret appears once. Copy it and keep it safe. Zapier and Make do not need it; your own server uses it to check the signature. If you lose it, create a new one with “Change secret”.
6. On the receiver card click “Send a test”. The result says Delivered or Not delivered with the reason.

The address must be public and start with https. These are rejected, and the page names the reason: http addresses, IP addresses instead of a domain, custom ports, addresses with a login and password, internal addresses and addresses on ReceptionWorks domains. The page shows only the host and path of the address: the part after the question mark can hold your receiver's token.

Which events are sent

• “New conversation” (conversation.started): a customer started a new conversation in any channel. Test chats and blocked customers are not sent.
• “Team member requested” (conversation.handoff_requested): the AI employee or the system asked for a team member. The event carries the reason: the AI employee’s own request, stopped automatic replies, manual mode, an unavailable AI employee, an exhausted reply limit or an inactive plan.
• “Conversation handed to a team member” (conversation.handed_off): a team member took the conversation over. It is sent every time.
• “New booking”, “Booking changed” and “Booking cancelled” (booking.created, booking.changed, booking.cancelled): a booking was made, changed or cancelled by an AI employee, by you in the calendar or by the business assistant.
• “New support request” (support_case.created) and “Support request changed” (support_case.updated): a support request was created, or its status, priority or description changed. Internal team notes are not sent.
• “New message” (message.created): every message a customer can see, sent as it is written: from the customer, the AI employee, a team member or the system (a notice in the conversation). The message text is included.
• “Conversation transcript” (conversation.transcript): the whole conversation, sent once the conversation has had no messages for 30 minutes. If the conversation continues, it is sent again after each later pause.

Events from the test chat are not sent. A receiver gets only events that happen after it was added and while it is on: what happened while it was paused or turned off is not sent later.

“New message” and “Conversation transcript” carry the full text of conversations, including what customers write. The text leaves ReceptionWorks and goes to the receiver you chose, so tick them only for receivers you trust. A new receiver starts with these two unticked. They are sent only while some receiver has them ticked, and they do not appear in the event log or its export: the dialog itself is in the inbox. Test chats and blocked customers are not sent.

What the receiver gets

Every event is a POST request with a JSON body. Example for a request for a team member made by an AI employee:

{
  "schema_version": "business-webhook.v1",
  "id": "5b0c5e2e-0000-4000-8000-000000000001",
  "type": "conversation.handoff_requested",
  "occurred_at": "2026-10-07T09:30:00.000Z",
  "business": { "name": "Example Studio" },
  "actor": { "kind": "ai_employee" },
  "channel": "telegram",
  "employee": { "name": "Anna" },
  "conversation": { "url": "https://app.example.com/businesses/studio/inbox?conversation=example" },
  "customer": { "name": "Maria", "email": "maria@example.com", "phone": "+1 555 0100" },
  "booking": null,
  "handoff": { "reason": "ai_request", "reason_text": "The customer wants to discuss a discount" },
  "support_case": null
}

• id: the event id. It stays the same on every retry, so ignore an id you have already processed.
• type: the event type from the list above; occurred_at: the time in UTC.
• business: the name of your business.
• actor: who caused the event. kind is customer, ai_employee, team_member (a team member or the business assistant) or system.
• channel: web, telegram, instagram, whatsapp or messenger, or null when the event has no conversation.
• employee: the name of the AI employee, or null when the team or the business assistant acted.
• conversation.url: a link to the conversation; it opens for signed-in team members. null when there is no conversation.
• customer: name, email and phone as known at the moment of sending, or null. Contacts are sent in full, so add only receivers you trust.
• booking: only for booking events: service, starts_at, ends_at, status and location.
• handoff: only for “Team member requested”: reason (ai_request, automation_stopped, manual_mode, ai_unavailable, quota_exhausted or plan_inactive) and reason_text, the AI employee’s own explanation or null.
• support_case: only for support request events: subject, status (open, in_progress, waiting_customer, resolved or closed) and priority (low, normal, high or urgent).
• message: only for “New message”: id, sequence (the position of the message in the conversation), author (customer, ai_employee, team_member or system), text, created_at and attachments: a list of kind (always image), name and media_type. Only the name and type of an attachment are sent, not the file itself.
• transcript: only for “Conversation transcript”: message_count (messages in the conversation), truncated and messages: messages in the same shape as message. A transcript holds up to the 500 most recent messages and 512 KiB of text; truncated is true when older messages were left out.

Sections that do not apply to the event are null. The “Send a test” event has the type webhook.test, and every section except business is null. The data carries no translated text: names are as saved, codes are fixed English words, and times are in UTC.

"message": {
  "id": "6c1d0f52-0000-4000-8000-000000000002",
  "sequence": 12,
  "author": "customer",
  "text": "Hello, can I book for Friday?",
  "created_at": "2026-10-07T09:29:41.000Z",
  "attachments": [{ "kind": "image", "name": "photo.jpg", "media_type": "image/jpeg" }]
}

Messages and transcripts can arrive out of order and can repeat, so do not rely on arrival order. Use sequence to restore the order of messages in a conversation, and drop a delivery whose webhook-id you have already processed. A transcript repeats messages you may already have received one by one: use it to check or rebuild the whole conversation.

How to check the signature

Each request has three headers of the Standard Webhooks standard: webhook-id, webhook-timestamp and webhook-signature. Zapier and Make do not check them. On your own server use the official Standard Webhooks library for your language: give it the secret exactly as shown (it starts with whsec_), the raw unchanged request body and the three headers. To check by hand:

signed_content = webhook-id + "." + webhook-timestamp + "." + raw request body
signature      = "v1," + base64( HMAC-SHA256( key, signed_content ) )
key            = base64-decoded part of the secret after "whsec_"

The webhook-signature header holds v1, followed by the signature. After “Change secret” it holds two signatures separated by a space: accept the request if either matches. Reject requests whose timestamp differs from your clock by more than five minutes.

Retries and automatic shutdown

The receiver must answer with a 2xx code within 10 seconds. Redirects are not followed: an address that redirects counts as an error. Otherwise ReceptionWorks tries again: right away, then after 1 minute, 5 minutes, 30 minutes, 2 hours, 6 hours and 12 hours. That is 7 attempts over about 21 hours. If all fail, the delivery is marked Not delivered in “Delivery log”, and you can click “Send again”. Retries carry the same webhook-id, so the receiver can drop duplicates.

A receiver is turned off automatically when it answers that the address no longer exists (code 410) or when five events in a row are not delivered. The card then shows “Turned off automatically” with the reason, and your team gets a notification. Fix the address and click “Turn on”: events missed in the meantime are not sent.

Pause, new secret, deletion

• “Pause” stops sending without deleting the receiver; click “Turn on” to continue.
• “Change secret” and then “Create new secret”: a new secret is shown once. The old one keeps working for 24 hours so you can update the receiver without losing events.
• “Delete” and then “Delete receiver” remove the receiver for good.

Good to know

• Only the Owner and the Administrator manage integrations. A business can have up to 5 receivers.
• The delivery log shows event, receiver, time, status, attempts and the next attempt. It keeps no request text.
• Testing with “Send a test” does not create a log entry and does not need a real event.

What's next

• Event log and export
• Messages: conversations with customers
• Team and roles