Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Webhook Collection

You can create Webhooks to be notified about any changes of the property's ARI or about booking and some OTA specific webhooks. Webhooks are Push-notifications. When any changes happens, we send a POST request with JSON payload to the provided endpoint.

Webhooks can be global (related to whole account) or property-related. Global webhooks allow you have single point to manage endpoints, credentials and don't worry about that when new property is added. Property-level webhooks is suitable to setup specific logic for signle property.

Webhook UI

We have an UI available to view, add and edit webhooks also so you can lessen your development efforts if you wish to manually set up instead of via API.

Property Webhooks: https://staging.channex.io/organization/webhooks/property

Global Webhooks: https://staging.channex.io/organization/webhooks/global

Global Webhooks

By default, webhooks are scoped to a single property. Global Webhooks allow you to receive events for all properties associated with your account through a single webhook endpoint, removing the need to create and manage individual webhooks per property.

How It Works

To create a Global Webhook, set property_id to null and is_global to true in your webhook configuration:

{
  "webhook": {
    "callback_url": "https://your-website.com/api/push_message",
    "event_mask": "*",
    "property_id": null,
    "is_global": true,
    "request_params": {},
    "headers": {},
    "is_active": true,
    "send_data": true
  }
}

Global Webhooks support the same event types, payload structures, and configuration options (send_data, event_mask, headers, request_params) as property-level webhooks. Every payload includes the property_id field, so your endpoint can identify which property triggered the event.

When to Use Global Webhooks

Global Webhooks are ideal when:

  • Your system manages many properties and you want a centralized event handler rather than one webhook per property.

  • New properties are added frequently and you want them covered automatically without additional webhook setup.

Important Notes

  • Global Webhooks and property-level webhooks can coexist. If both are configured for the same event and property, your endpoint will receive only 1 webhook event. Property level webhook win.

Webhook Security

Channex webhooks currently do not include a built-in HMAC signature or cryptographic signing mechanism similar to Stripe/GitHub webhook signatures.

Webhook authentication is instead designed around:

  • HTTPS endpoints

  • Custom shared-secret headers

  • Optional IP allowlisting

  • Your own replay/idempotency handling

Recommended Authentication Approach

When registering a webhook endpoint, we recommend including a custom secret header such as:

Your application should validate this secret on every incoming webhook request.

Use:

  • long random secrets

  • HTTPS only

  • separate secrets per environment

  • secret rotation where appropriate

IP Allowlisting

For additional security, you may optionally restrict incoming webhook traffic to known Channex IP ranges where supported by your infrastructure.

Important Notes

  • Do not expose webhook endpoints publicly without validation.

  • Do not rely solely on source IP validation.

  • Always validate incoming payload structure before processing.

  • Webhooks should be treated as untrusted external input.

Webhook repeat logic

When we receive unexpected 5XX error from your webhook endpoint we make a new attempt for delivery with exponential backoff timeout. Max count of attempts is 10. Timeouts between attempts: - 1 minute - 2 minutes - 4 minutes - 8 minutes - 15 minutes - 30 minutes - 1 hour - 2 hours - 4 hours - 6 hours - 10 hours

So, latest attempt will be close to 24h from original event.

List of webhook events available

  • ari This will send you any ARI changes like changed availability or prices, useful if you allow users to change ARI in the Channex interface or mobile app and also to integrate any RM system

  • booking If you wish to get all booking changes then this is the one, you will get notification for any booking revision new, modified and cancelled.

  • booking_new Will be triggered only for Booking Revisions with status new.

  • booking_modification Will be triggered only for Booking Revisions with status modified.

  • booking_cancellation Will be triggered only for Booking Revisions with status cancelled.

  • booking_unmapped_room This will let you know if any bookings were created which were not mapped

  • booking_unmapped_rate Similar to unmapped room but this means room is mapped but rate is not

  • non_acked_booking Will be triggered when Booking Revision will be not acknowledged at 30 minutes after first receiving.

  • message If you use the messaging API this is required to push messages to you in real time

  • sync_error You can see any sync errors on your dashboard

  • sync_warning Will be triggered if some non-critical errors will be returned by OTA on sync.

  • rate_error Will be triggered if error associated with Rate values will be returned by OTA on sync.

  • reservation_request Airbnb specific, You can see a reservation request and can accept or deny.

  • alteration_request Airbnb specific, You can see an alteration request and can accept or deny.

  • accepted_reservation Airbnb specific, will be triggered when Reservation request will be accepted.

  • declined_reservation Airbnb specific, will be triggered when Reservation request will be declined.

  • inquiry Airbnb specific, You can see an inquiry request at Dashboard and Messages App.

  • review This will let you know if any new review is came.

  • updated_review Will be triggered when Review object will be updated (Guest feedback will be received).

  • new_channel Will be triggered when new Channel will be created for Property.

  • updated_channel Will be triggered when Channel is updated.

  • disconnect_channel Will be triggered when Channel is disconnected by automatic rules or User action.

  • disconnect_listing Will be triggered when Listing is disconnected from Airbnb Channel.

  • activate_channel Will be triggered when Channel is activated.

  • deactivate_channel Will be triggered when Channel is deactivated.

Webhooks List

get

Retrieve a list of webhooks associated with the user's properties.

Authorizations
user-api-keystringRequired
Query parameters
pagination[page]integer · int32Optional
pagination[limit]integer · int32Optional
Responses
200

The request has succeeded.

application/json
get/webhooks

Get Webhook by ID

get

Retrieve a specific webhook by ID.

Authorizations
user-api-keystringRequired
Path parameters
webhookIdstring · uuidRequired
Responses
200

The request has succeeded.

application/json
get/webhooks/{webhookId}

Create Webhook

post

Create a new webhook.

Authorizations
user-api-keystringRequired
Body
Responses
201

The request has succeeded and a new resource has been created as a result.

application/json
post/webhooks

Update Webhook

put

Update an existing webhook.

Authorizations
user-api-keystringRequired
Path parameters
webhookIdstring · uuidRequired
Body
Responses
200

The request has succeeded.

application/json
put/webhooks/{webhookId}

Remove Webhook

delete

Remove a webhook.

Authorizations
user-api-keystringRequired
Path parameters
webhookIdstring · uuidRequired
Responses
200

The request has succeeded.

application/json
delete/webhooks/{webhookId}

Test Webhook

post

Test a webhook by sending a test POST request to the callback URL. Returns the status code and body from the target endpoint.

Authorizations
user-api-keystringRequired
Body
Responses
200

The request has succeeded.

application/json
status_codeinteger · int32Required

HTTP status code returned by the callback URL.

Example: 200
bodystringRequired

Response body returned by the callback URL.

Example: { "success": true }
post/webhooks/test

Payloads

No Data Version

The message is provided to the provided webhook endpoint, depending on the webhook settings (send_data). If send_data is true, Channex will push the message payload, if false message payload will be removed and target endpoint will only receive event, user_id and property_id fields.

Webhooks with data payload

ARI (Availability, Rates & Restrictions)

Triggered when any changes have happened at the property State or inventory table. We provide information about changed prices, restrictions and availability.

Note: We have included the user ID of who generated the changes, this can be useful if you would like to ignore changes made by your own app.

Booking

Triggered when Channex receives a booking revision (New, Cancelled or Modified).

This event was originally designed to trigger a Pull booking revision operation from the PMS. When this event arrives, we expect the PMS will call api/v1/booking_revisions/:id, to pull the new revision and ack it.

Alternatively the PMS can call the Feed endpoint also to get list of all unack bookings.

Booking Unmapped Room

Triggered when Channex receives a booking revision but can’t map it with existing Room Types. This can happen if the channel is not mapped correctly or if the OTA provides ID which has no mapping.

This event is designed to notify PMS about potential problems at mapping and usually used to trigger notification to support team at PMS side to investigate problems with mapping.

Please, keep in mind, to prevent any potential problems with overbookings, Mapping Issues should be solved in short time-frame and should have high priority.

Booking Unmapped Rate

Triggered when Channex receives a booking revision but can’t map it with existing Rate Plans.

This trigger will not come if revision has not mapped Room Type error. Booking Unmapped Room event will mute Booking Unmapped Rate, because when we have no mapped Room it also means rate is not mapped.

This event is designed to notify PMS about potential problems at mapping, but in that case, we can map Room (and correctly process Availability changes), but can’t map to Rate Plan.

Message

Triggered when new chat message from a guest is registered at Channex.

Sync Error

Triggered when sync error has happened at a connected channel.

Originally designed to notify PMS about potential problems at existed connections.

Reservation Request

Triggered when Channex receives a Reservation Request from Airbnb.

Contains information about requested reservation.

Where BOOKING_MESSAGE is structure equal to regular Booking Revision structure.

Review

Triggered when Channex receives a Review.

Activate / Deactivate Channel

Non Acked Booking

Airbnb Inquiry

Webhook message sequence

Before you start any integration with webhooks, you should to know -

Sequence of incoming webhook calls can be different from sequence of events which trigger that calls. Webhooks may come out of order.

Explanation

At property A we have 2 state changes event: Change availability for Room Type A from 0 to 1. Change availability for Room Type A from 1 to 0.

This events triggers 2 webhook calls with ari type. But when Channex sends the first webhook we might catch some network issue at middle level and message failed with a timeout error. This is a temporary error and webhook will be rescheduled. Second webhook had no issues and was sent successfully and would arrive first.

PMS receives webhook #2 with Availability 0. First webhook is queued for 2nd attempt to be sent to the target endpoint and this time all went well and we deliver that webhook.

PMS receive webhook #1 with Availability 1.

As a result, if PMS will interpret incoming results, this can cause problems. Instead use information from payload, we suggest to use webhooks as a trigger to execute logic to pull ARI info from Channex.

So, in case with Availability changes, we suggest instead using data from payload, trigger a pull request to get values for changed dates.

PreviousAvailability and RatesNextBookings Collection

Last updated