Skip to main content

Runbook: Repush Booking When Failed Push to OTA Service

ServiceChannelku V1 / Channelku V2
Owner Team slack handle[@bnl-team-a]
Team's Slack Channel#bnl-ota-notification

Table of Contents​

Alert / Notificationincident.io
alert with title Failed Push to OTA Service is raised when a booking's XML fails to be delivered to the OTA service
Manual Resend EndpointResend Manual Booking
OTA Service EndpointOTA Service

1. Triage​

Quickly identify the affected booking and confirm whether it still needs to be repushed to the OTA service.

  • 1. Get the Booking ID from the alert:

    • Open the alert in incident.io and confirm the title is Failed Push to OTA Service.
    • Copy the Booking ID from the alert details.

  • 2. Check whether the booking has already been handled:

    • In incident.io, check whether another alert for the same Booking ID has already been acknowledged or resolved with a repush note by another engineer.

  • 3. Check whether the OTA service is reachable:

    curl -o /dev/null -s -w "%{http_code}" https://ota.bookandlink.com/health

    Expected result: 200. If the result is 5xx, 000, or a timeout, the OTA service is experiencing issues.

2. Decision Point​

Interpret the triage results using the following conditions:

  • IF the same Booking ID has already been repushed by another engineer (duplicate alert)...

  • IF the Booking ID has not been repushed yet...

3. False Alarm​

The booking has already been repushed by another engineer after the alert was raised. There is no active incident. However, the failure should still be monitored, as repeated alerts indicate the OTA service is unstable.

  1. Re-confirm in the other alert's note that the Booking ID matches and the repush returned the generated XML.
  2. Resolve the alert in incident.io with a note referring to the alert where the booking was already repushed.

4. True Incident​

The booking's XML has not been delivered to the OTA service. Until it is repushed, the OTA availability for the booked dates is out of sync. The first priority is to repush the booking manually.

4.1. Recover the System​

The following are the most likely root causes, ordered from most common to least common.

Potential Cause 1: Temporary Push Failure​

The OTA service is healthy (health check returns 200), but the push for this booking failed once, e.g. due to a timeout or a short network issue.

Remediation Plan:

  1. Repush the booking manually by opening the resend endpoint in a browser, replacing [token] and [booking_id]: 
    https://api-channelku.bookandlink.com/api/resend-manual-booking?token=[token]&booking_id=[booking_id]
    Example for booking ID 52675175: 
    curl "https://api-channelku.bookandlink.com/api/resend-manual-booking?token=[token]&booking_id=52675175"

Verification:

  1. A successful repush returns the booking info and the generated XML: 
    Booking ID : 52675175
    Booking Date : 2026-09-25
    URL : https://ota.bookandlink.com/utility/ota_update.php?propertyid=3078&priceflag=0&alotflag=1&stopsellflag=0&minflag=0&inclusionflag=...
    Generated XML :
    <request>
      <propertyid>3078</propertyid>
      <otaids>5,6,10,12,13,14,34,43,79,103,161</otaids>
      <bookingrowid>52675175</bookingrowid>
      <callingLoc>Bookings by [user_email] ([ip_address])</callingLoc>
      <timestamp></timestamp>
      <updatereq priceflag="0" alotflag="1" stopsellflag="0" minflag="0" inclusionflag="0" ctaflag="0"></updatereq>
      <daterange day="2026-10-05" rateplan_id="27302" Alot="22"></daterange>
      <daterange day="2026-10-05" rateplan_id="27303" Alot="22"></daterange>
      ...
      <daterange day="2026-10-09" rateplan_id="81710" Alot="18"></daterange>
    </request>
  2. Confirm the following in the response:
    • bookingrowid matches the Booking ID from the alert.
    • alotflag="1", which means an allotment update was sent.
    • There is a daterange entry for each stay date and rate plan of the booking.

Potential Cause 2: OTA Service is Down or Overloaded​

The OTA service is unresponsive or returning errors, so the manual repush also fails (no Generated XML block in the response, or an error is returned).

Diagnostic Steps:

  1. Check whether the OTA service endpoint is reachable: 
    curl -o /dev/null -s -w "%{http_code}" https://ota.bookandlink.com/health
    Expected result: 200. If the result is 5xx, 000, or a timeout, the OTA service is experiencing issues.

Remediation Plan:

  1. If the OTA service is confirmed down, do not repeatedly force the manual repush — wait until the health check returns 200 again.
  2. Once the OTA service recovers, repush the booking using the steps in Potential Cause 1.
  3. If the OTA service stays down or the repush keeps failing while the health check returns 200, escalate to @bnl-team-a in #bnl-ota-notification with the Booking ID and the response.

Verification:

  1. The manual repush returns the generated XML as shown in Potential Cause 1.

4.2. Clean Up​

Once the booking is successfully repushed, the next step is to close the alert, communicate with stakeholders, and ensure no other booking was missed.

  1. Verify the repush response contains the generated XML with the correct bookingrowid.

  2. Resolve the alert in incident.io with a note containing the Booking ID and the time of the repush.

  3. Check for other open Failed Push to OTA Service alerts in incident.io and repeat this runbook for each Booking ID.

  4. Create or update the post-mortem ticket if several alerts came in within a short time, or the same booking keeps failing, with the following details:

    • Timestamp of the initial failure and time of resolution.
    • Identified root cause.
    • Total number of affected bookings.
    • Action items to prevent recurrence.
    • Assign to @bnl-dev for review in the next sprint.