A withdrawal is when a guest cancels their own pending booking request before the partner has acted on it. When this happens, the request moves to the WITHDRAWN_PENDING_APPROVAL status.
Withdrawals are triggered by the guest. A request can be withdrawn while it is in the CREATED status. That is, after the guest sends it but before the partner approves or rejects it. Once the partner has acted, the request can no longer be withdrawn.
Withdrawals apply to both RtB flows:
- INQUIRY flow (version 1.x). The request was informational and did not hold inventory, so a withdrawal simply ends the request.
- RTB flow (version 2.x / RtB 2.0). The pending request held provider-side inventory, so a withdrawal means you must release that inventory. See What providers must do.
A withdrawn request is returned with:
| Property | Value |
|---|---|
| Status name | WITHDRAWN_PENDING_APPROVAL |
| Meaning | The guest withdrew the request while it was pending approval. No reservation will be created. |
The status appears in the requestStatus field of the Booking Request object and can be used as a status filter when listing booking requests.
The WITHDRAWN_PENDING_APPROVAL status is an incremental feature added to both major versions. To receive it, send the matching X-Booking-Api-Version header:
| Major version | Minimum version |
|---|---|
| 1.x (INQUIRY flow) | 1.1.0 |
| 2.x (RTB flow, RtB 2.0) | 2.1.0 |
For the full version history, see Versioning.
On version 2.x (RTB flow, RtB 2.0): the required action depends on the request's requestType. For RTB requests, treat WITHDRAWN_PENDING_APPROVAL the same way you treat REJECTED, EXPIRED_PENDING_APPROVAL, and FAILED_TO_PROCESS. That is, release the provider-side availability you blocked when the request was created, and propagate that release across your channels. Releasing the hold promptly returns the inventory to your other channels. For INQUIRY requests there is no hold to release (they do not block inventory while pending), so no availability change is required. See RtB 2.0 availability management for the complete status-based availability rules.
On version 1.x (INQUIRY flow): there is no pending hold to release, because inquiry requests do not block inventory while pending. Handle the status so it can be shown to your users, but no availability change is required.