Disclosure: we make Avelyn. The full, non-technical guide for business owners is on our blog: Online booking on WordPress for coaches and studios.

1. A free time is not just "not booked"

A start time is offered only when all of these are true:

• it lies inside the opening hours of that weekday (with an optional second range for a lunch break),
• the date is not in the closed-dates list,
• it is later than now + minimum notice and earlier than today + days ahead,
• the service length plus the break after it fits before the range ends,
• it does not overlap another booking, including that booking's break.

In code that is an interval check, not an equality check:

// $start / $end in Unix time; $buffer = break after, in seconds.
function overlaps( $start, $end, $buffer, $booked ) {
    foreach ( $booked as $b ) {
        if ( $start < $b['end'] + $b['buffer'] && $b['start'] < $end + $buffer ) {
            return true;
        }
    }
    return false;
}

2. Two people, one slot, same second

Two clients can click the last free time at the same moment. Re-checking availability just before saving is not enough. You need a short lock around "check + insert" so the second request sees the first booking. We use an option-based lock with a short expiry, which works on shared hosting without extra database tables.

3. Time zones

Everything is stored in UTC and shown in the site time zone from Settings → General → Timezone. Choose a city, not a UTC offset, so summer time is handled. The booking widget shows the time zone label next to the times; coaches with international clients get far fewer "is that my time or yours?" e-mails.

4. Calendar files and links

Every confirmation e-mail has:

The cancel link respects a limit (for example 24 hours before), and the client gets a reminder e-mail a set number of hours before the start.

5. Classes are a different problem

A class is a fixed weekly time with a capacity, so the questions change:

• How many spots are left right now?
• Has this e-mail address already reserved this exact class time?
• When the class is full, can people join a waitlist?
• When someone cancels, the first person on the waitlist is confirmed automatically and gets an e-mail.

We also keep a small "My bookings" list in the visitor's browser (localStorage), so people can see which classes they reserved on that device without creating an account.

6. The boring parts that matter

• Spam: a hidden honeypot field plus a rate limit per visitor on every public endpoint.
• E-mail delivery: many hosts do not deliver mail sent by WordPress. The docs tell users to install an SMTP plugin, and the first test booking proves it works.
• Privacy: bookings are registered with WordPress's personal data exporter and eraser, so a "delete my data" request covers them too.
• Payments: we deliberately do not charge at booking time. Packages, passes and gift cards are WooCommerce products. It keeps booking simple and lets each business choose its payment provider.

7. Settings people can actually find

Our first version used the WordPress Site Editor for page design. Business owners wanted one place for everything, so version 1.1 moved to a single settings panel: business details, colors and fonts, header and footer, and the sections, texts and photos of every page, next to the booking rules.

Checklist if you are choosing a booking tool

• Breaks between appointments and two ranges per day
• Minimum notice and "days ahead"
• Time zone shown on the booking page
• .ics file, Google Calendar link and an online cancel link
• Waitlist for classes
• No double bookings under load
• Works with WordPress's privacy tools

The long version, written for coaches and studio owners rather than developers, is here: Online booking on WordPress for coaches and studios.

This post covers what to check so that every order reaches your automation exactly once.

What WooCommerce gives you out of the box

WooCommerce has built-in webhooks under WooCommerce → Settings → Advanced → Webhooks. For each one you choose a topic (for example Order created), a delivery URL and a secret. WooCommerce then signs every request with an X-WC-Webhook-Signature header: a base64 HMAC-SHA256 of the body, made with your secret.

That covers the basics, with three things to watch:

1. Failed deliveries add up. After a number of consecutive failures (5 by default, set by the woocommerce_max_webhook_delivery_failures filter) WooCommerce disables the webhook. Nothing tells you, and new orders stop flowing until someone notices.
2. "Order created" is not "order paid". An order is created before the payment is confirmed. If your workflow sends a welcome e-mail or creates an invoice, trigger it on the paid status, and make sure it runs once even if the status changes again.
3. Debugging is blind. When something fails you want the exact body that was sent and the exact answer your server gave.

A checklist for reliable delivery

• Send in the background. The webhook should never slow down checkout. Queue the request and send it after the order is saved.
• Retry with a delay. A short outage should mean "delivered a few minutes later", not "lost".
• Never switch an endpoint off silently. If deliveries keep failing, alert someone instead.
• Fire "paid" once per order. Store a flag on the order so a second status change does not run the workflow again.
• Log every attempt with request body, response code and response body, and keep a "resend" button.
• Verify the signature in n8n so nobody can post fake orders to your public webhook URL.

Verifying a signature in n8n

You do not need any code for this. As an example, the open-source NodeThemes Webhooks plugin, which I maintain, sends an X-NT-Signature header: sha256= followed by an HMAC-SHA256 of the timestamp and the body, so an old request cannot simply be replayed. In n8n:

1. Webhook node: receives the order.
2. Crypto node: Action = Hmac, Type = SHA256, Encoding = hex, Secret = your endpoint secret, and as Value:

{{ $json.headers["x-nt-timestamp"] }}.{{ JSON.stringify($json.body) }}

3. If node: continue only when "sha256=" + the Crypto result equals {{ $json.headers["x-nt-signature"] }}.

The plugin sends the body in a form that JSON.stringify reproduces exactly, which is what makes step 2 work. For other senders, check this first: if the bytes differ, the signature will never match. Two more habits help:

• Reject old timestamps, for example anything older than five minutes.
• Deduplicate. A retry or a manual resend carries the same event ID (X-NT-Event-Id). Store the IDs you have handled and skip repeats, so a retry never sends a second SMS or creates a second invoice.

If you would rather skip signatures, an authentication header checked by n8n's Header Auth is a simpler alternative.

For WooCommerce's own webhooks the idea is the same, but the signature is the base64 HMAC of the body only, in the X-WC-Webhook-Signature header.

How the plugin handles the rest

The free plugin covers the checklist above for up to three endpoints:

• events for order created, order paid (once per order), status changed, completed and cancelled,
• sending in the background with Action Scheduler, so checkout never waits,
• three automatic retries over about 15 minutes; an endpoint is never switched off by itself,
• an HMAC-SHA256 signature on every request, plus an optional authentication header,
• a delivery log with the exact body, the answer and the error, and one-click resend,
• HPOS and block checkout support.

Whether you use it or WooCommerce's built-in webhooks, test the failure case on purpose: stop n8n, place a test order, start n8n again, and check that the order still arrives.

The full step-by-step guide, with screenshots of the n8n workflow, is on the NodeThemes blog: WooCommerce n8n Integration: Step-by-Step Guide.