> ## Documentation Index
> Fetch the complete documentation index at: https://partner.headout.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Submit reschedule request for booking

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`](/docs/api-partner/v2/bookings/get) — on success, the booking's `startDateTime` / `endDateTime` will reflect the new slot. On failure, the booking remains on its original slot.

<Warning>
  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.
</Warning>

See [Cancellation & reschedule lifecycle](/docs/guide/key-concepts#cancellation-%26-reschedule-lifecycle) for the full flow, including concurrency and retry rules.

<RequestExample>
  ```bash cURL theme={"theme":{"light":"github-light","dark":"github-dark"}}
  curl -X POST \
    "https://www.headout.com/api/public/v2/bookings/12345/reschedule/" \
    --header 'Headout-Auth: <YOUR_API_KEY>' \
    -H "Content-Type: application/json" \
    -d '{
      "startDateTime": "2025-11-02T09:00:00",
      "endDateTime": "2025-11-02T11:00:00",
      "comment": "Shift to morning slot"
    }'
  ```
</RequestExample>


## OpenAPI

````yaml POST /api/public/v2/bookings/{bookingId}/reschedule/
openapi: 3.1.0
info:
  title: Headout API Docs - API Partner v2
  version: 0.0.1
servers:
  - url: https://www.headout.com
    description: Production server
  - url: https://www.sandbox-headout.com
    description: Sandbox server
security: []
paths:
  /api/public/v2/bookings/{bookingId}/reschedule/:
    post:
      tags:
        - Bookings
      summary: Submit reschedule request for booking
      operationId: v2RescheduleBooking
      parameters:
        - name: bookingId
          in: path
          required: true
          schema:
            type: string
          description: Booking identifier owned by the calling partner.
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/PartnerRescheduleRequest'
      responses:
        '200':
          description: Acknowledgement of reschedule submission or business-rule failure
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/PartnerRescheduleAck'
        '401':
          description: Missing or invalid `Headout-Auth`
        '403':
          description: Partner not active, not an API Partner, or booking not owned by key
      security:
        - apiKeyAuth: []
components:
  schemas:
    PartnerRescheduleRequest:
      type: object
      required:
        - startDateTime
        - endDateTime
      properties:
        startDateTime:
          type: string
          format: date-time
          description: >-
            Desired new start date and time for the booking. Timezone offset is
            optional — if omitted, local time is assumed. See [ISO
            8601](https://en.wikipedia.org/wiki/ISO_8601).
        endDateTime:
          type: string
          format: date-time
          description: >-
            Desired new end date and time for the booking. Timezone offset is
            optional — if omitted, local time is assumed. See [ISO
            8601](https://en.wikipedia.org/wiki/ISO_8601).
        comment:
          type:
            - string
            - 'null'
          description: Optional free-text comment explaining the reason for rescheduling.
    PartnerRescheduleAck:
      type: object
      description: >
        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](/api-partner/v2/bookings/get).
      properties:
        success:
          type: boolean
          description: >-
            Whether the reschedule request was accepted into the asynchronous
            fulfilment queue. `true` does not mean the reschedule has been
            fulfilled.
        message:
          type: string
          description: Human-readable message describing the acknowledgement outcome.
  securitySchemes:
    apiKeyAuth:
      type: apiKey
      in: header
      name: Headout-Auth

````