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

# Rescheduling & cancellation

> How bookings change state, who can change them, and what happens to reminders

Bookings aren't frozen at creation. Each booking moves through a
defined lifecycle, and several parties can transition it. This
page summarises who can do what and what propagates to the rest
of the system.

## Lifecycle states

A booking is always in exactly one state:

| State                  | Meaning                                                                       |
| ---------------------- | ----------------------------------------------------------------------------- |
| `scheduled`            | Booked and confirmed; waiting for the slot.                                   |
| `pending_confirmation` | Awaiting customer confirmation (when the preset requires it).                 |
| `confirmed`            | The customer acknowledged the booking.                                        |
| `started`              | The meeting has begun.                                                        |
| `completed`            | The meeting ended cleanly.                                                    |
| `cancelled`            | The booking was cancelled by admin, agent, customer, or API.                  |
| `no_show`              | The grace window passed with no one joining.                                  |
| `rescheduled`          | A superseded record that was replaced by a newer booking at a different time. |

The exact transitions happen automatically (on join, on end, on
grace window expiry) or manually (cancel, reschedule).

## Who can change what

| Action         | Admin | Agent (assigned) | Customer                 | API |
| -------------- | ----- | ---------------- | ------------------------ | --- |
| Create         | ✅     | ✅                | ✅ (public page)          | ✅   |
| Reschedule     | ✅     | ✅                | Optional — preset toggle | ✅   |
| Cancel         | ✅     | ✅                | Optional — preset toggle | ✅   |
| Reassign agent | ✅     | ✅ (on their own) | ❌                        | ✅   |
| Mark no-show   | ✅     | ✅                | ❌                        | ❌   |

The preset controls whether customers are allowed to reschedule or
cancel on their own. When those are off, the customer has to
contact the agent.

## What happens on reschedule

When a booking is rescheduled:

1. The old scheduled time moves to the booking's history; the new
   time becomes the active `scheduled_at`.
2. Pending reminders for the old time are **cancelled**.
3. New reminders are **planned** against the new time.
4. If [Genesys pre-meeting dispatch](/guides/scheduled-calls/genesys-integration)
   was configured, any prior dispatch record is cleared and a new
   one is scheduled for the new time.
5. A `rescheduled` event is written to the timeline and
   `scheduled.rescheduled` is pushed to any configured webhook.

The booking's **meeting link stays the same**. A customer who had
the link from a prior reminder can still use it to join the new
slot — they don't get a new URL.

## What happens on cancel

1. The booking moves to `cancelled` with a timestamp, the actor,
   and an optional reason.
2. Pending reminders are **cancelled**.
3. If the preset has the `cancellation` reminder enabled, that
   one fires so the customer is informed.
4. A `cancelled` event is written to the timeline and
   `scheduled.cancelled` is pushed to webhooks.

Cancellation is **soft** — the row is kept for auditing, reporting,
and reactivation. It's never hard-deleted.

## No-show

If the slot passes and nobody joined (or the agent joined but the
customer never showed), the platform marks the booking
`no_show` after a short grace window. The `scheduled.no_show`
webhook fires at that point.

An agent can also mark a no-show manually from the booking
detail.

## Confirmation flow (optional)

When the preset has **"require customer confirmation"** enabled:

* New bookings start in `pending_confirmation`.
* The customer receives an invitation with a confirm link.
* On confirmation they move to `confirmed`.
* If they don't confirm before the configured window closes, the
  booking is auto-cancelled with reason `unconfirmed_auto_cancel`.

This is a way to filter out flaky bookings before you commit agent
time to them.

## What's next

<CardGroup cols={2}>
  <Card title="Reminders" href="/guides/scheduled-calls/reminders">
    What gets sent on create, reschedule, and cancel.
  </Card>

  <Card title="Webhooks" href="/guides/scheduled-calls/webhooks">
    Events your systems receive for every state change.
  </Card>
</CardGroup>