Skip to main content
POST
Submit a reschedule request for a booking owned by your partner account. Reschedule is a two-phase operation:
  1. Synchronous acknowledgement (this endpoint). The endpoint validates input, ownership, and business rules (eligibility, cutoff window, valid future date/time) and enqueues an asynchronous job. A 200 response with success: true means the request was accepted into the queue — it does not mean the reschedule has been fulfilled. A 200 with success: false means the request was rejected up-front (e.g. business-rule failure) and no async job is enqueued.
  2. Asynchronous fulfilment. The reschedule is processed against the supplier in the background. The final outcome — whether the booking was actually moved to the new slot — is reflected on the booking itself.
To learn the final outcome:
  • Consume booking webhooks — a successful reschedule re-books the booking, so you receive a PENDING then a COMPLETED event for the same bookingId (the transient internal CANCELLED is suppressed, so no CANCELLED webhook is sent), or
  • Poll Get Booking — on success, the booking’s startDateTime / endDateTime will reflect the new slot. On failure, the booking remains on its original slot.
Because a reschedule internally cancels and re-books, a poll landing mid-reschedule can transiently return CANCELLED before the booking returns to PENDING → COMPLETED. CANCELLED is not terminal here — don’t treat a CANCELLED poll result as a cancellation while a reschedule is in flight.
See Cancellation & reschedule lifecycle for the full flow, including concurrency and retry rules.

Authorizations

​
Headout-Auth
string
header
required

Path Parameters

​
bookingId
string
required

Booking identifier owned by the calling partner.

Body

application/json
​
startDateTime
string<date-time>
required

Desired new start date and time for the booking. Timezone offset is optional — if omitted, local time is assumed. See ISO 8601.

​
endDateTime
string<date-time>
required

Desired new end date and time for the booking. Timezone offset is optional — if omitted, local time is assumed. See ISO 8601.

​
comment
string | null

Optional free-text comment explaining the reason for rescheduling.

Response

Acknowledgement of reschedule submission or business-rule failure

Synchronous acknowledgement of the reschedule submission. Does not represent the final reschedule outcome.

  • success: true — the request passed validation and business-rule checks (eligibility, cutoff window, valid future date/time) and was enqueued for asynchronous fulfilment against the supplier. The booking's startDateTime / endDateTime will update only after fulfilment succeeds.
  • success: false — the request was rejected up-front and no asynchronous job was enqueued.

Learn the final outcome via booking webhooks or by polling Get Booking.

​
success
boolean

Whether the reschedule request was accepted into the asynchronous fulfilment queue. true does not mean the reschedule has been fulfilled.

​
message
string

Human-readable message describing the acknowledgement outcome.