Skip to main content

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.

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:
StateMeaning
scheduledBooked and confirmed; waiting for the slot.
pending_confirmationAwaiting customer confirmation (when the preset requires it).
confirmedThe customer acknowledged the booking.
startedThe meeting has begun.
completedThe meeting ended cleanly.
cancelledThe booking was cancelled by admin, agent, customer, or API.
no_showThe grace window passed with no one joining.
rescheduledA 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

ActionAdminAgent (assigned)CustomerAPI
Create✅ (public page)
RescheduleOptional — preset toggle
CancelOptional — 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 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

Reminders

What gets sent on create, reschedule, and cancel.

Webhooks

Events your systems receive for every state change.