Skip to main content

Public booking status for bookings

Summary​

The Public API now exposes a booking status in API terms, separate from the internal payment status naming used by Semble.

Bookings can now return status on the Booking type, and createBooking / updateBooking accept an optional status input for supported slot reservation and confirmation flows.

This change is additive. Existing clients can continue to use the existing booking fields.

What changed​

The new public enum is BookingStatus:

Public valueMeaning
pendingThe slot is reserved but not confirmed yet.
processingConfirmation or payment processing is in progress.
confirmedThe booking is confirmed.
failedConfirmation or payment failed.

Confirmed bookings may be backed internally by either no payment status or a completed payment status. Public API clients should use Booking.status rather than relying on internal payment terminology.

Create and update behaviour​

  • createBooking(status: pending) reserves the slot and does not send patient confirmation messages.
  • createBooking(status: confirmed) creates a confirmed booking when the selected product does not require payment.
  • updateBooking(status: confirmed) confirms an existing non-payment booking and sends confirmation side effects according to sendPatientMessages.
  • Manual confirmation is rejected for products that require payment; those bookings must be confirmed by the payment flow.

Example​

mutation ReserveBooking($bookingData: BookingDataInput!) {
  createBooking(bookingData: $bookingData) {
    data {
      id
      status
    }
    error
  }
}

Example variables:

{
  "bookingData": {
    "patient": "PATIENT_ID",
    "location": "LOCATION_ID",
    "bookingType": "PRODUCT_ID",
    "start": "2026-06-19T09:00:00.000Z",
    "end": "2026-06-19T09:30:00.000Z",
    "status": "pending"
  }
}

Integration guidance​

  • Treat Booking.status as the public booking lifecycle field for new integrations.
  • Parse BookingStatus values defensively so clients can tolerate future enum additions.
  • Use pending only when your integration is intentionally reserving a slot before confirmation.
  • Use confirmed only for non-payment bookings; payment-required bookings must complete through the payment flow.

See also​