# Deletes one or more bookings

`DELETE /api/bookings`

- **Success:** `200 OK`
- **Products:** Operator (`FOH`), Consumer (`CONSUMER`) (any one of these products, not all)
- **Features:** Online Bookings (`ONLINEBOOK`), Front of House Generic Access (`FOHGENERIC`) (any one of these features, not all)

HTML version: [Deletes one or more bookings](https://support.gladstonesoftware.cloud/reference/bookings/deletes-one-or-more-bookings)

## Overview

Cancels a batch of bookings in one call. For each booking, every member booked on to it is
removed; a booking that has nobody on it is deleted outright.

**This endpoint is deliberately partial.** It returns `200 OK` with the ids sorted into three
lists — `deleted`, `notFound` and `notDeleted` — and it returns `200` even when nothing at all was
deleted. Read the body, not the status code, and expect to reconcile: some ids can succeed while
others fail in the same request.

One check does apply to the whole batch before anything is touched. If **any** of the bookings has
attendance recorded against it, the call fails with `400` and nothing is deleted, however many of
the others were fine. Attendance is therefore the one failure you never see reflected in
`notDeleted` — drop the attended ids and send the rest.

Bookings are cancelled member by member, so a booking with several members on it can be left half
cancelled if a later member fails: the earlier deletions stand, and the id is reported in
`notDeleted`. Re-sending the same id is safe — the members already gone are simply not there any
more.

To remove a booking that has no members on it, and only that, use
[Delete a booking completely and utterly](delete-a-booking-completely-and-utterly-its-gone-for-good-its-an-ex-booking-now.md).
To release a hold that was never confirmed into a booking, use
[Delete a booking lease](delete-a-booking-lease.md) instead.

## Endpoint

`DELETE {base_url}/api/bookings`

`{base_url}` is the environment URL issued to your integration. See [Authenticating with Gladstone APIs](../../guides/authenticating-with-gladstone-apis.md).

## Query parameters

| Name | Type | Required | Description |
|------|------|----------|-------------|
| `bookingIds` | string | Yes | The bookings to cancel, as a **comma-separated list in a single parameter** — `?bookingIds=101,102,103` — not a repeated parameter. Required despite the schema marking it optional: omitting it or sending it empty fails with `One or more Booking IDs must be specified`. Every entry must parse as an integer of `1` or more, or the whole request fails with `The given booking ID of {value} must be an integer greater than zero` before anything is deleted. Ids that do not exist are not an error here; they come back in `notFound`. |

## Sample request

```bash title="cURL"
curl -X DELETE '{base_url}/api/bookings' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'
```

## Response fields

| Field | Type | Description |
|-------|------|-------------|
| `deleted` | array of integer | The bookings that were fully cancelled — every member removed, or the empty booking deleted. These are done; do not re-send them. |
| `notFound` | array of integer | The bookings that could not be located while being cancelled: no booking with that id, or a member on it that the delete could not resolve. Treat these as already gone rather than retrying — a repeat produces the same result. |
| `notDeleted` | array of integer | The bookings that were found but rejected or errored — for example one that can no longer be cancelled, or a server-side failure part-way through. **No reason is returned**, only the id, so inspect the booking to find out why. A multi-member booking listed here may have had some of its members removed before the failure. |

## Sample response

```json title="200 OK"
{
  "deleted": [
    101,
    102
  ],
  "notFound": [
    103
  ],
  "notDeleted": [
    104
  ]
}
```

## Errors

| Status | Meaning | When |
|--------|---------|------|
| `400` | Bad request | `bookingIds` is missing or empty — `One or more Booking IDs must be specified`. |
| `400` | Bad request | An id in the list is not a positive integer — `The given booking ID of {value} must be an integer greater than zero`. Nothing is deleted; fix the list and send it again. |
| `400` | Bad request | At least one booking in the batch has attendance recorded — `At least one of the bookings has attendance recorded against it and cannot be deleted.` **Nothing in the batch is deleted**, including the bookings that would have succeeded. |
| `400` | Bad request | The attendance check itself failed — `The booking attendances could not be verified: {message}`, where `{message}` is passed through from the bookings service. Nothing is deleted. |
| `404` | Not found | The attendance check could not find one of the bookings — `The booking attendances could not be verified: {message}`. This is the batch-level check, so nothing is deleted; an id that is merely unknown at deletion time is reported in `notFound` with a `200` instead. |
| `500` | Internal server error | Any unexpected server-side failure, with an empty body. Failures on an individual booking do not reach here — they are absorbed into `notDeleted`. |