Set up website bookings

Guide customers into WagDay, match the widget to your brand, verify its website installation, and test the full booking journey.

The booking widget lets customers request a booking from your website. Admins set it up under Settings → Booking Widget using five guided stages.

1. Customer access

Choose whether first-time visitors may send a guest request from the embedded widget.

When Allow new customers is on, first-time visitors can enter their details and request a booking from the website.
Existing customers use the single Customer access link. They sign in, choose a saved pet and continue in the customer portal.

Copy or open that same universal customer access link, or expand its QR code when you need a scannable version. You do not need a separate app link.

2. Brand and booking rules

Set the primary colour, welcome message and approval policy shown to customers. The preview responds while you edit; select Save changes to publish those settings to the real widget.

The widget follows your facility's WagDay settings; deposits are configured on each service under Catalog → Services, not as a separate widget-wide rule.

Add each exact website origin that may load the widget, including its protocol and port when one is present. Then add the exact Widget page URL, including its path and an optional simple anchor such as #booking.

Use HTTPS for real websites. Local HTTP is accepted only while WagDay is running in development, and only for localhost, IPv4 addresses in 127.0.0.0/8, or ::1. Test and unknown environments do not enable that exception. URLs containing a username/password or hash-router path such as #/book or #!/book are rejected; use a dedicated page and an ordinary anchor instead.

The installation status is factual:

Configured (shown as Ready to install) means the website details have been saved and the embed code is ready to paste.
Connected means WagDay received a current one-time proof from the exact saved page and allowed origin.

Saving a website address does not make it Connected. Changing the page URL, allowed origins or widget key clears the previous proof, so test the installation again after making those changes.

To install and verify it:

Save the website origin and widget page URL.
Select Copy embed code and paste it where bookings should appear on the website. The raw code stays collapsed unless you choose to show it.
Publish the website change.
Select Test installation. WagDay opens the saved page and waits briefly for its one-time proof.

If the test cannot confirm the page, check for a blocked popup, a redirected page URL, a hash-router address such as #/book, old or missing embed code, or the wrong website origin.

An empty allowed-origin list is a legacy “any website” configuration. Add an exact website origin before testing; an unrestricted configuration cannot become Connected.

The Connected state and the View live widget links are derived from the saved page, its proof timestamp, and the current exact allowed-origin list. A stale label or proof for a now-disallowed site never enables those links.

4. Test the customer journey

The safe preview cannot submit a booking. Use it to check the saved branding and layout on desktop and mobile.

For a full customer-to-staff check, use the installed widget's Sign in action, follow the universal customer access path, sign in as an existing customer, select a saved pet and available service or time, and submit once. Then confirm the matching request in the staff booking action queue.

You may separately test the optional new-customer guest form when guest requests are enabled. Keep this distinct from the signed-in customer path: a guest request is not an authenticated registration.

WagDay does not mark this journey complete automatically. The final staff-record check is a deliberate operator acceptance step.

Going live

You can configure and verify the website before going live. Connected proves the installation; Live controls whether customers can use the public portal and widget. Complete the onboarding go-live step when you are ready to accept real customer traffic.

Key rotation takes effect immediately. It invalidates every installed embed snippet, the universal customer access link and all generated QR codes, and it clears the installation proof.

Use Advanced: security and recovery → Rotate widget key only when the current key may be exposed. Type ROTATE to confirm, replace every affected website and shared artifact, then test the installation again.

Rotation is concurrency-safe: WagDay reserves the replacement route, changes the tenant key only if the old key is still current, and reconciles a competing or uncertain result to the currently routable key. A replacement-route failure leaves the tenant key unchanged.

What happens when a customer books

The booking is priced using your normal service rules and checked against capacity.
Guest requests are accepted only while the freshly rechecked saved policy explicitly allows them. An email already belonging to a customer is sent to sign in before pet, price, booking or notification work.
Guest requests create tenant-scoped customer, pet and request records without overwriting an existing customer's details.
Staff receive the request in WagDay when approval is required; otherwise a request may confirm automatically when availability allows.

Reliability and security boundaries

The customer-experience summary reflects saved settings, not unsaved edits. Saving locks the controls and stage rail until the request finishes; validation opens the first invalid stage and focuses the exact field, including the relevant approved-website row.
Browser portal sessions are accepted only for the facility opened through its validated customer link. A different facility fails closed without deleting the original facility's cookie. Native app bearer sessions remain authoritative for their own organisation.
Proof requests are protected first by independent per-IP limits of 30 POSTs and 60 preflights per minute, then by the existing per-IP-and-widget limits of 10 and 30. Public booking requests have a 30-per-minute per-IP aggregate and the existing 10-per-minute scoped limit; booking JSON is limited to 16 KiB.
The local installation fixture serves its key-bearing page only at the exact bound 127.0.0.1:<port> authority and prevents framing. If the embed loader cannot safely remove a proof token from the URL fragment, it skips the proof callback and still loads the normal widget configuration.
Unsaved changes use the standard reload warning plus supported internal-navigation interception. External, download, new/named-target, modifier, non-primary, exact-current and same-page-anchor links are not intercepted. Browsers without interceptable Navigation API support cannot reliably block every back/forward or programmatic transition.
The settings workspace stacks on narrow screens, pairs settings with preview at tablet size, and uses three columns when wide. Public widget rows respond to the embed container rather than only the viewport, with at least 44px form and sign-in targets; checkbox interaction is enlarged through its label rather than the checkbox square.
The service module has an explicit server-only boundary. Security-sensitive proof polling/popup behavior and credential recovery are isolated modules: one secure popup opens synchronously, polling is single-flight and monotonic, only a newer proof succeeds, timeout is 14 seconds, and leaving the stage or unmounting cancels the run. A failed rotation preserves the previous proof.

What's next?

New to WagDay and bringing data across? Importing from PetManager
Tune your booking rules: Booking cutoffs and date blocking