# Listings

Discover and retrieve bookable listings

## Retrieve the full bookable catalogue (paginated, venue-aggregated)

 - [GET /v1/listings](https://docs.bookabletech.com/apis/production/listingsapiv1/listings/getlistings.md): Returns the entire bookable catalogue available to the caller, paginated and
venue-aggregated. Results are grouped by operator (ListingGroup); each group
carries its venues (ListingItem), and each venue carries one Listing per
capability it offers (table_reservation, event_ticket).

A venue that also hosts a ticketed event therefore appears once, with two
entries in its capabilities[] — one per capability. Optional query filters
(capability, name, location, features, date, …) narrow the catalogue; with no
filters the whole catalogue is returned page by page.

## Check availability for multiple bookable products in one call

 - [POST /v1/availabilities](https://docs.bookabletech.com/apis/production/listingsapiv1/listings/checkavailabilities.md): Batch availability check. Modelled as a command (POST), not a search.

The request carries root-level date, quantity and optional time, plus
a bookableProducts[] list. Each entry has a required compositeId and may
override date, quantity and time. When an entry omits any of those,
the root-level value is used.

quantity carries the count for either capability, same as in POST /v1/orders
— number of covers for a table reservation, number of tickets for an
event-ticket line.

Every entry must end up with date and quantity resolved (either from
the entry or the root). time is optional — event capabilities are queried
by date alone; for table reservations it narrows the slot when supplied. An
entry that cannot resolve date and quantity is reported as an error
result and does not block the others.

Searches run independently: a failure on one compositeId yields an error
on that result only — all other results are returned normally. The response
carries one AvailabilityResult per requested compositeId, preserving
request order.

There is no 404 response: an unknown/nonexistent compositeId is not a
request-level failure — it's reported as an error on that entry's
AvailabilityResult, same as any other per-entry failure (e.g. unresolved
date/quantity), never as an HTTP-level not-found for the whole call.