> ## Documentation Index > Fetch the complete documentation index at: https://docs.1club.ai/llms.txt > Use this file to discover all available pages before exploring further. # Bookings > Create, edit, cancel, and take payment on reservations for areas, classes, and instructors. A booking is the unit of revenue. Every reservation - a member joining a class, renting an area, booking a one-on-one with an instructor, or buying an [event ticket](/operations/events) - is stored as a booking row with one or more transactions attached. The list page lives at **Operations > Bookings**; the detail page is where you handle payment, check-in, cancellation, and notes. If you haven't picked a check-in flow yet, start with [Check-in models](/reference/check-in-models). The payment and cancellation rules are set per [booking policy](/operations/booking-policies). ## The list page The bookings list has four tabs with live counts: **All**, **Upcoming**, **Past**, and **Cancelled**. Upcoming is the default tab. Each tab is paginated and sortable; the cancelled tab uses a dedicated endpoint with a leaner response shape. Click any row to open the booking detail page. Click **Add booking** in the top right to create one from scratch. ## Creating a booking The booking dialog has three sections: * **Contact** - pick the member from your contacts. If the matching [booking policy](/operations/booking-policies) allows anonymous bookings, the contact is optional and admins can record bookings for people who don't have a profile yet. * **Type** - pick **Area**, **Class**, or **Instructor**. Each routes to its own selector (gym filter applies). Selecting a class also locks the date/time to the class occurrence. * **Schedule** - start time, end time, and notes. The booking duration step from the policy controls how the end time snaps to allowed lengths. The price breakdown appears below the type section. It shows the line item (area price per hour, instructor price, or class price), any promotion or manual price adjustment, and the total. If membership benefits or external programs cover the booking, that's reflected here. At the bottom of the create dialog, **Send confirmation email** controls whether the member gets the confirmation. It's checked by default; uncheck it when you're recording a booking that's already been communicated out-of-band. The checkbox is only on create - editing an existing booking does not re-send confirmation. Admin-created bookings bypass the **At booking** payment enforcement so you can record a reservation that will be paid later. The balance is still collected before check-in unless the policy is set to **None**. See [Booking policies](/operations/booking-policies) for the three enforcement modes. ## The booking detail page The detail page header shows the booking title with status chips (confirmed, pending, cancelled, paid/unpaid) and a row of actions: **Add payment**, **Notify participants**, **Edit**, **Cancel**, and (when the booking is `pending`) **Confirm**. Once a booking is confirmed and within the check-in window, an **Add check-in** action also appears. The body uses a two-column layout. The left column is the info table: created at, created by with the booking **source** (one of `admin`, `portal`, `app`, `network`, `website`, `kiosk`, `integration`, `api`), customer or coach, recurrence summary, entrance method, and any discount. The right column lists **Players** for area bookings whose area type allows multiple participants (each player can carry their own per-share payment) and shows a yellow note card if the booking has notes. When the booking is part of a multi-line order, the order summary is rendered alongside the info table so you can see the other lines and the order total. Cancelled bookings show a red alert at the top with the cancellation reason, timestamp, and the user who cancelled. Event-ticket bookings are titled with the event name, the order line item names the event and ticket type, and the booking's transaction reference reads `Event: {title} - {ticket}`. See [Events](/operations/events) for the attendee list and check-in. Below the info layout, three tabs hold the booking's financial and audit history: * **Transactions** - every transaction tied to the booking, with payment status and remaining balance. * **Payments** - every payment across those transactions (most useful for split or partial payments). * **Bookings** - only shown for recurring bookings; lists sibling occurrences in the same recurrence series. When you switch a booking's entry to a **membership** or an **external program**, the booking's total price is reset to 0. A membership has no per-booking charge, and an external program bills through its own per-visit transaction - so the booking itself carries no price. Switching back to a paid entry recalculates the price. ## Paying for a booking The **Add payment** action opens the payment dialog. If the booking has one outstanding transaction, the amount is editable and defaults to the remaining balance. If the booking has multiple outstanding transactions (for example, a recurring series or a multi-line order), the amount is locked to the sum of all remaining balances and the server settles them atomically. Partial multi-transaction payments are not supported - use the Transactions tab to pay them individually. The right-click and mobile-tap menus on the [Schedule](/operations/schedule) page expose the same **Add payment** action without opening the booking. ## Cancellations The cancel action opens a dialog where you record a reason. The refund follows the [cancellation rules](/operations/booking-policies) on the matching policy: tiered refund percentages based on how many hours in advance the cancellation happens. If no cancellation rules are configured on the policy, the cancellation refunds 100%. The cancellation creates a refund transaction (visible on the Transactions tab) and emits a cancellation notice to the member. The booking row moves to the **Cancelled** tab. ## Recurring bookings When the booking type is area or instructor, you can set a recurrence pattern in the dialog. Editing a recurring booking lets you change the current instance only, or apply changes to all future occurrences. Deleting offers the same scoping. The **Bookings** tab on the detail page lists every sibling occurrence in the recurrence series. ## Related * [Booking policies](/operations/booking-policies) - Payment timing, cancellation refunds, lead times. * [Schedule](/operations/schedule) - The calendar where these bookings show up. * [Classes](/operations/classes) - Class-bound bookings have their own list and detail flow. * [Events](/operations/events) - Event tickets become bookings with their own attendee list and check-in. * [Payments](/billing/payments) and [Transactions](/billing/transactions) - Money side of every booking. * [Check-in models](/reference/check-in-models) - Entrance method that satisfies payment-at-check-in.