Scheduler

Publish bookable appointments, meetings, classes or reservations with availability, capacity and optional payment and connected-service features.

Create a booking type

1. Install core and activate CalendarWP - Scheduler.
2. Create a booking type. Review its duration, capacity, host, availability and location.
3. Publish it directly or connect it to a CalendarWP event.
4. Make a free test booking first. Check its date, timezone, status and customer-facing details.
5. Enable reminders and external services only when needed, then test those configured workflows separately.

Set the timezone deliberately and verify a date around a daylight-saving change when relevant. A published event or available calendar date alone does not establish a bookable slot; availability is checked by the booking workflow.

Payments and shared connections

Provider credentials are managed by an administrator under CalendarWP > Options > Integrations. Scheduler's Connected Services controls how Scheduler uses those shared accounts.

Paid bookings need Stripe credentials and the correct webhook endpoint/signing secret. Use Stripe test mode and test payment details before using live keys. Check the resulting booking and webhook outcome; do not infer a settled payment from the browser redirect alone. Keep secrets and payment references out of public support posts.

Google Calendar can support the enabled conflict-check and booking-calendar features through the site's shared connection. A connected badge alone does not prove a booking was written to Google. Granola imports retrieve notes into WordPress; the built-in webhook does not itself import or match notes. Do not promise fully automatic recap matching on the basis of a connection test.

Reminders, tickets and delivery status

Background recovery depends on WordPress Cron. Review diagnostic and booking status when a reminder or ticket email is delayed. Transport acceptance means the sending service accepted a message, not that the recipient received it.

Uncertain reminder or ticket-email outcomes can be marked delivery needs review. Dedicated organizer resolution/resend controls for those uncertain outcomes are not implemented in this version. Do not repeatedly resubmit bookings or promise automatic resend. Keep the original booking and diagnostic context for support.

Tickets support QR/manual check-in where configured. Access links and attendee data are private; do not share them publicly. Review staff permissions before allowing booking or attendance management.

Update, troubleshoot and remove

Back up the database and plugin files together. When upgrading from before Scheduler 1.0.34/RSVP 1.0.25, pause new booking requests and independent workers, let in-flight work finish, then update both affected add-ons before resuming. See the booking-lock update procedure. This change does not convert existing bookings.

If a booking is missing or pending, inspect its current status, availability, payment mode and webhook delivery before retrying. For delayed background work, inspect WordPress Cron. For provider failures, retain the displayed error without copying credentials or customer records into public reports.

Configure retention intentionally. Deactivation is not a request to erase bookings. Read Privacy and data and preserve a backup before uninstalling or enabling removal.

Applies to Scheduler 1.0.35. Optional external-service scenarios need testing for the site's actual configuration; the guide does not imply every provider interruption scenario has been certified.