Webhooks

Overview

Webhooks allow your application to receive real-time notifications when data changes in BookingShake. Instead of polling the API for updates, BookingShake automatically sends HTTP POST requests to your specified endpoint whenever an account, contact, or payment is created, updated, or deleted - or when an invoice is issued. Why use webhooks?

Real-time updates: Receive notifications instantly when data changes
Reduced API usage: No need to continuously poll for changes
Efficient: Only get notified about events you care about
Scalable: Build reactive integrations that sync data automatically

Common use cases:

Sync contacts and accounts to external CRM systems (Salesforce, HubSpot, etc.)
Sync invoices and payments to your accounting software or ERP
Trigger automated workflows when new contacts are created
Update analytics dashboards in real-time
Maintain data consistency across multiple platforms

Quick Start

Access Webhook Settings

In your BookingShake dashboard, go to Settings > Integrations and scroll to the Webhooks section.

Create a Webhook

Click New Webhook and configure:

Name: A descriptive name for your webhook (e.g., “CRM Sync”)
URL: Your HTTPS endpoint (e.g., https://api.yourdomain.com/webhooks/bookingshake)
Events: Select which events to receive (see available events below)

Save and Copy Secret

After saving, copy the webhook secret. You’ll need it to verify webhook signatures for security.

Test Your Webhook

Create or update a contact or account to trigger a test webhook delivery.

Available Events

BookingShake supports sixteen webhook events:

Event	Description	Triggered When
`booking.created` ^Beta	New booking created	A booking (dossier) is created via the app or the API
`booking.updated` ^Beta	Booking modified	Any relevant change on the booking or its events, including status changes
`booking.deleted` ^Beta	Booking removed	A booking and all its events are deleted
`quote.created` ^Beta	Quote issued	A quote PDF is generated (including new versions)
`quote.updated` ^Beta	Quote lifecycle changed	Sent, validated/signed, canceled, validity or PDF updated
`quote.deleted` ^Beta	Quote removed	A quote is deleted
`account.created`	New account created	A company is added to your venue
`account.updated`	Account modified	Company information is updated
`account.deleted`	Account removed	A company is deleted
`contact.created`	New contact created	A person is added to your venue
`contact.updated`	Contact modified	Contact information is updated
`contact.deleted`	Contact removed	A contact is deleted
`invoice.created` ^Beta	Invoice issued	An invoice, deposit invoice, balance invoice, or credit note is generated
`payment.created` ^Beta	New payment recorded	A payment is added to a booking
`payment.updated` ^Beta	Payment modified	Payment information is updated (amount, status, dates…)
`payment.deleted` ^Beta	Payment removed	A payment is deleted

Booking, quote, invoice and payment events are currently in beta: their payload structure may still evolve before general availability.

Each resource has a dedicated page with payload examples and field reference:

Booking Events

Bookings (dossiers): created, updated, deleted - full payload with nested events

Quote Events

Issued quotes: created, updated (sent/validated/signed), deleted

Account Events

Companies: created, updated, deleted

Contact Events

People: created, updated, deleted

Invoice Events

Full invoice payload: amounts, lines, frozen seller/buyer blocks, e-invoicing fields

Payment Events

Lightweight payment payload with invoice and booking correlation keys

You can subscribe to multiple events in a single webhook. Select only the events you need to reduce unnecessary traffic.

Webhook Payload Structure

All webhooks follow this consistent structure:

{
  "event": "contact.created",
  "timestamp": 1731493800000,
  "venue_id": "venue123",
  "venues_group_id": "group456",
  "data": {
    // Event-specific data (see examples below)
  }
}

Payload Fields

Field	Type	Description
`event`	string	The event type (e.g., `contact.created`)
`timestamp`	number	Unix timestamp in milliseconds when the event occurred
`venue_id`	string	The venue ID where the change happened
`venues_group_id`	string \| null	The venues group ID if applicable
`data`	object	Event-specific data containing the resource details

HTTP Headers

Each webhook request includes these headers:

Content-Type: application/json
User-Agent: Bookingshake-Webhooks/1.0
Bookingshake-Signature: <hmac-sha256-signature>
Idempotency-Key: <unique-uuid>

Header Details

Header	Description
`Content-Type`	Always `application/json`
`User-Agent`	Identifies the request as coming from BookingShake webhooks
`Bookingshake-Signature`	HMAC SHA256 signature for verifying authenticity (see Security)
`Idempotency-Key`	Unique UUID for this delivery attempt - use to prevent duplicate processing

Custom Fields

Account and contact webhooks include custom fields configured for your venue (invoice and payment payloads do not expose custom fields). Custom fields are prefixed with custom_ followed by a UUID:

{
  "event": "contact.created",
  "data": {
    "id": "contact-456",
    "first_name": "John",
    "last_name": "Doe",
    "custom_5d07ff93-9b23-4e37-8654-4661fcfd8da8": "VIP Customer",
    "custom_7a12bc34-5de6-4f78-9012-3456789abcde": [0, 1, 2]
  }
}

Custom field values can be strings, numbers, arrays, or objects depending on your field configuration.

Venue vs Venues Group Webhooks

When creating a webhook, you can choose the scope: Venue-level webhooks: Receive events only for a specific venue

Use when you want separate webhook endpoints per venue
Useful for venue-specific integrations

Venues group webhooks: Receive events for all venues in a group

Use when you want a single endpoint for multiple venues
More efficient for managing multi-venue organizations
The venue_id field identifies which venue triggered the event

Next Steps

Security & Verification

Learn how to verify webhook signatures and implement security best practices

Error Handling

Understand error codes and how to handle failures

API Reference

Explore the BookingShake API for additional functionality

Support

Contact our support team for assistance

Rate Limits and Delivery

Delivery timeout: Your endpoint must respond within 5 seconds with a 200-299 status code.Retry policy: Failed deliveries are automatically retried up to 10 times with exponential backoff.Status monitoring: Check your webhook status in the dashboard to track delivery success and failures.

Getting Started

REST API

Guides

Webhooks

Overview

Quick Start

Available Events

Booking Events

Quote Events

Account Events

Contact Events

Invoice Events

Payment Events

Webhook Payload Structure

Payload Fields

HTTP Headers

Header Details

Custom Fields

Venue vs Venues Group Webhooks

Next Steps

Security & Verification

Error Handling

API Reference

Support

Rate Limits and Delivery

​Overview

​Quick Start

​Available Events

Booking Events

Quote Events

Account Events

Contact Events

Invoice Events

Payment Events

​Webhook Payload Structure

​Payload Fields

​HTTP Headers

​Header Details

​Custom Fields

​Venue vs Venues Group Webhooks

​Next Steps

Security & Verification

Error Handling

API Reference

Support

​Rate Limits and Delivery

Overview

Quick Start

Available Events

Webhook Payload Structure

Payload Fields

HTTP Headers

Header Details

Custom Fields

Venue vs Venues Group Webhooks

Next Steps

Rate Limits and Delivery