WAITLISTIZE

Description

WAITLISTIZE connects WordPress to the external Waitlistize booking service. A Waitlistize account and explicit approval by that account’s administrator are required. The plugin is free; SaaS subscription permissions are determined by Waitlistize. There are no plugin license keys or paid plugin feature unlocks.

• Native single appointment and group event booking, with backend availability and booking rules.
• Dynamic Booking and Service catalog blocks plus account-bound shortcodes using the same renderer.
• Confirmed, pending and waitlisted outcomes and service-configured redirects from Waitlistize.
• Read-only, paginated account booking list with date, service ID and status filters.
• WordPress editors can insert blocks; only administrators with manage_options can read customer records or manage the connection.
• Per-site Multisite isolation; WordPress.org language-pack support; local scripts and styles.

Booking changes, cancellations, approvals, rescheduling and waitlist management stay in Waitlistize. Admin links require normal Waitlistize login and account permission. The native backend list includes active waitlist records, distinguished from bookings. Records are shown regardless of booking source. Customer names and account-timezone dates are displayed without persisting the booking list in WordPress.

The service catalog shows public services. Inactive service administration and subscription plan details are not provided by the current API. The Overview labels these limits explicitly. Existing embeds retain their attributes when new-block display defaults change.

External service and privacy

This plugin uses Waitlistize. Read its Terms of Service and Privacy Policy before connecting.

No integration requests are made before an administrator starts connecting. Starting pairing sends the target account slug, site name, HTTPS URL, random installation identifier, public client identifier and requested services:read, availability:read, public_bookings:create and bookings:read permissions to Waitlistize. Approval happens on the Waitlistize website. Compare the site URL and security code; approval does not prove domain ownership.

After approval, WordPress exchanges and refreshes credentials, retrieves account identity, service information, available times/events and admin booking records, and revokes the connection on request. Public service data reaches editors and visitors; only authorized site administrators can access the minimal booking-list fields (customer name, service, time, status and admin link).

When a visitor submits a booking, WordPress forwards the selected slot/event, required name/email/phone fields, required privacy acceptance, separate optional newsletter consent where configured, form timing, honeypot and visitor IP/user-agent to Waitlistize. The browser talks to WordPress; API credentials remain server-side. Waitlistize handles booking decisions, storage and any configured notifications/integrations. Visitor data passes through WordPress but is not stored in a plugin booking table or booking-list cache. Hosting, security or third-party plugins can have their own logs: configure them to protect personal data and credentials.

Credentials are encrypted in non-autoloaded per-site options using Sodium. Encryption does not protect a fully compromised WordPress site. No device codes, access tokens or refresh tokens are localized into scripts or returned to the browser. There are no remote executable scripts, CDN assets, built-in analytics or automatic downloads of executable code.

Disconnect deletes local credentials before remote revocation. If remote revocation cannot be confirmed, revoke the site in Waitlistize Settings > Integrations > WordPress. Uninstallation erases local credentials and display defaults without network requests; disconnect first to revoke remotely. WordPress page content is retained.