Skip to main content
POST
A hold reserves a room with the supplier without making the booking final. You get time to collect payment from your customer, then confirm. This endpoint makes a held booking final. It sits after Create Booking in the flow: prebook, create booking with booking_mode: "HOLD", wait for ON_HOLD, confirm hold. Holds exist only for TripJack offers. You can tell from the prebook response: data.offer.lifecycle.available_booking_modes is ["INSTANT", "HOLD"], hold_allowed is true, and hold_deadline shows until when the supplier lets you hold. Every other offer lists only INSTANT.

The hold flow

1

Prebook and check the offer allows a hold

In the prebook response, lifecycle.hold_allowed is true and available_booking_modes contains HOLD.
2

Create the booking as a hold

Call Create Booking with "booking_mode": "HOLD". It returns PROCESSING. A hold request whose deadline is less than 2 days away goes to AWAITING_REVIEW instead.
3

Wait for ON_HOLD

The booking becomes ON_HOLD (a booking.updated webhook announces it, or poll Get Booking Status). Now hold_deadline_at (UTC) is set, processing_reason is HOLD_CONFIRMATION_REQUIRED, action_required is true and available_actions contains CONFIRM_HOLD.
4

Confirm before the deadline

Call this endpoint with the booking’s accepted_offer_id. The booking moves to PROCESSING, then CONFIRMED.
Collect your customer’s payment between steps 3 and 4, and only confirm when you have it.
Confirm before hold_deadline_at. TripJack may cancel an unconfirmed hold automatically after the deadline. Do not rely on the hold lasting longer.

Request

There is no amount or payment field. Confirmation uses the supplier amount already bound to the accepted offer, so nothing can change between hold and confirm.

Response

The response has the same shape as every booking response. After this call, wait for the booking.confirmed webhook or poll Get Booking Status until the status is CONFIRMED, then issue the voucher. Do not call confirm-hold again for an uncertain outcome; it is verified automatically.

Outcomes

Calling confirm-hold on a booking that is already PROCESSING or CONFIRMED (with the right accepted_offer_id) is harmless: it returns the current state and does not send a second confirmation. A HOLD_CONFIRMATION_REJECTED response is also announced as a booking.updated webhook moving the booking from PROCESSING back to ON_HOLD. Its details include the supplier’s HTTP status:

Error codes

If you do nothing (the hold lapses)

You do not have to confirm. If the guest does not pay, leave the hold alone, or cancel it yourself while it is ON_HOLD (CANCEL is in available_actions; see Cancellation Quote and Cancel Booking). After hold_deadline_at the supplier may cancel it, and confirm-hold returns HOLD_DEADLINE_EXPIRED. Keep checking the booking status for the final state; never show a guest a held booking as confirmed. This follows TripJack’s hold-then-confirm process. See the TripJack API documentation.

Authorizations

x-api-key
string
header
required

Environment-specific API key created in the Unifystays portal

Headers

X-Unifystays-Contract-Version
enum<string>
default:2

Hotel API contract version. Optional: 2 is the current version and the default.

Available options:
2

Path Parameters

booking_id
string
required

Unifystays booking ID (ubk_...) of a booking whose status is ON_HOLD and whose available_actions contains CONFIRM_HOLD.

Example:

"ubk_eGQ0dW9uV1Vi"

Body

application/json
accepted_offer_id
string
required

The accepted offer ID stored with this held booking. Prevents confirming a different revision accidentally.

Response

The confirmation was accepted (status PROCESSING, then CONFIRMED) or its outcome is uncertain and is being verified (PROCESSING). Do not call confirm-hold again; wait for booking webhooks or poll Get Booking Status. A booking that is already PROCESSING or CONFIRMED returns its current state.

contract_version
string
required

Response contract version. Always "2".

Example:

"2"

success
boolean
required

false only when the booking status is FAILED. true for every other status, including AWAITING_REVIEW and PROCESSING, which are not confirmations. Read data.status for the real state.

Example:

true

message
string
required

Human-readable summary for logs and support; for FAILED it carries the reason. Do not parse it; use data.status.

Example:

"Booking request accepted and is being processed."

data
object
required

The booking's current state.