Webhook delivery

Meetzi sends an HTTP POST to the target_url of each matching active subscription when a booking event is dispatched. Use webhook subscriptions to register and remove receivers.

Events

trigger_type	Booking event	When it is sent
new_booking	Booking Created	A new booking is created.
booking_cancelled	Booking Cancelled	A booking is cancelled.
booking_updated	Booking Rescheduled	A booking's start time or duration changes through rescheduling.

booking_updated requires the current status to be rescheduled, a valid start time, and a changed start time or duration. It is not a general notification for profile, question, approval, or other booking edits.

Matching subscriptions

For each event, Meetzi selects active subscriptions that:

• belong to the booking page's owner;
• match the dispatched trigger_type;
• either select that booking page or have no page filter.

An all-pages subscription also covers future pages owned by that user. Events from deleted pages are not delivered. Multiple matching subscriptions may each receive the event.

Callback request

POST /webhooks/meetzi HTTP/1.1
Host: example.com
Content-Type: application/json

The JSON body is the booking payload for the event. For example, a new_booking delivery contains the same booking object shown in the new bookings response, but without { "data": [...] } around it.

Meetzi does not add trigger_type, a delivery ID, a subscription ID, or an event timestamp envelope to the body. The subscription determines the event type. Use separate callback paths for different event types if your receiver needs to distinguish them.

Acknowledge delivery

Return a 2xx response after accepting the event. The response body is not used.

Receiver response	Meetzi behavior
2xx	Delivery is considered successful.
410 Gone	Delivery fails and Meetzi attempts to deactivate the subscription.
Other non-2xx	Delivery failure is logged. The subscription remains active.
Network error	Delivery failure is logged.

The current delivery implementation makes one attempt per matching subscription for each dispatched event. It does not provide automatic retries, replay, a guaranteed delivery order, or a webhook delivery history endpoint. Trigger lists expose recent records in their current state, not a replay of past events.

Receiver design

Use an HTTPS receiver and keep its callback URL private. Current deliveries include a JSON content-type header but no webhook signature or Authorization header. The Meetzi API key authenticates subscription management requests; it is not sent to your receiver.

Validate incoming payloads before processing them. If your receiver performs work asynchronously, durably queue the event before returning 2xx. Make processing safe to repeat: booking_id identifies a booking, but is not a unique event ID, since a booking can be rescheduled multiple times.

Subscription lifecycle

1. Load example records from a trigger endpoint to understand the booking payload.
2. Create a subscription with your receiver's target_url, the event type, and an optional page filter. Store the returned id.
3. Meetzi sends matching booking payloads to that URL.
4. Use the subscription id to deactivate the subscription when your integration no longer needs events.

To change an event type, callback URL, or page filter, deactivate the old subscription and create a new one. There is no subscription update or list endpoint in this API.