# Handling guest withdrawals

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.

## When a withdrawal can happen

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](#what-providers-must-do).


## Status: `WITHDRAWN_PENDING_APPROVAL`

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](/connectivity/docs/request-to-book/retrieving-booking-requests#bookingrequest-object) and can be used as
a `status` filter when [listing booking requests](/connectivity/docs/request-to-book/retrieving-booking-requests#list-booking-requests).

## API version requirements

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](/connectivity/docs/request-to-book/technical-overview#versioning).

## What providers must do

**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](/connectivity/docs/request-to-book/rtb-2.0/availability-management#status-based-availability-rules) 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.