Booking pages

A booking page publishes your availability at a public address so a guest can pick a slot without an exchange of messages. You set the slot length, how much notice you need, how far ahead people may book and how many bookings you will take in a day, a week and a month. Everything after that is a refinement of those rules: blackout ranges for the days you are away, questions a guest must answer before the slot is held, several meeting types on one page, and a host pool that shares incoming bookings across a team.

• A public page at /book/<slug> that a guest can use without an Atlas account, plus an embeddable version for your own website
• Rate limits at three horizons: a maximum per day, per week and per month, so a busy week cannot borrow against the next one
• Blackout date ranges for holidays and time away, which remove those days from the public page rather than letting somebody book and be turned down afterwards
• Pre-booking questions in eight types, each optionally required, so a slot is only held once you have what you need to prepare
• Several meeting types on one page, each with its own length, buffer and notice period, and each optionally restricted to specific members of the host pool
• A host pool with round-robin: every booking goes to the member with the lowest cumulative count, weighted so a part-time colleague takes proportionally fewer, and capped per day so nobody has a wall of calls
• A busy-time check against connected Google and Outlook calendars, so a slot you are already committed to never appears as free
• Branding on the public page: your logo, accent colour, company name and footer text
• Outbound webhooks on every booking, cancellation and reschedule, signed with HMAC-SHA256 so the receiver can verify the sender
• Guests cancel and reschedule themselves from a link in their confirmation, without going through you

• A page without a timezone is interpreted as UTC, which is almost never what was meant, and the settings screen says so with a control that applies your profile timezone. This matters most on a page created through the API, where the field can be left null.
• Round-robin only applies when the pool has at least one enabled member. With an empty pool, or with round-robin off, every booking goes to the page owner. That is deliberate: a page that silently accepted nothing because the pool was empty would be worse than one that falls back.
• The busy-time check is a silent no-op when the host has no connected calendar. Turning it on does not connect one, so connect the calendar first at Settings and Calendar, then enable the check.
• A webhook that fails is retried on a backoff schedule of thirty seconds, five minutes, thirty minutes, two hours and six hours, then soft-disabled after eight consecutive failures. Soft-disabled means the subscription is still listed and still yours to re-enable, not deleted.
• Blackouts and per-day caps remove slots from the public page. A guest never sees a slot they cannot have, which is why an over-tight cap reads as an empty page rather than as an error.
• Analytics on a booking page are scoped to you. The window is selectable at seven days, thirty days, ninety days or one year, which is how the control labels them, and the by-host breakdown names the people in your pool.

1. 1Open Settings and then Booking, and create a page with a name and a public address. The address is the last part of the public link and is what a guest sees.
2. 2Set the slot length, the buffer between slots, the notice you need before the first bookable slot, and how far ahead people may book.
3. 3Set the maximum bookings per day, and per week or per month if you want a ceiling across a longer horizon.
4. 4Set the timezone. Working hours are interpreted in it, and leaving it blank means UTC.
5. 5Open Advanced settings on the page for everything else: blackouts, questions, meeting types, the host pool, branding and webhooks.
6. 6Add teammates to the host pool and turn on round-robin if the page is for a team rather than for you. Set a weight to give somebody proportionally more or fewer bookings, and a daily cap to stop anybody being fully booked.
7. 7Copy the public link and share it, or use the embed version to put the page on your own site.
8. 8Check Analytics on the advanced screen to see bookings per day, the cancellation and no-show rates, and which meeting types and hosts are being chosen.

Why can a guest not see any slots?

Work through the four rules that remove slots: the notice period hides everything sooner than that, the maximum days ahead hides everything later, a blackout range removes whole days, and a per-day, per-week or per-month cap that is already met removes the rest. If the busy-time check is on, a slot that overlaps an event on your connected calendar is also hidden. A page with no slots at all usually means the working hours are empty or the page is paused.

How does round-robin decide who gets a booking?

The member with the lowest cumulative booking count wins, and a tie is broken by position in the pool. Weight scales that count, so a member on weight two absorbs roughly twice as many bookings as one on weight one. A member whose daily cap is already met for the candidate day is skipped entirely. If somebody joins the pool late, use Reset to clear their cumulative count so they are not permanently behind.

What happens to a booking when the guest cancels?

The slot is released and becomes bookable again, and your webhooks receive a cancellation event. The booking stays on the record so the cancellation rate on the analytics panel reflects it. A guest cancels from the link in their confirmation and does not need an Atlas account.

Can one page offer more than one length of meeting?

Yes. Add meeting types on the advanced screen, each with its own length, buffer and notice period. The guest picks the type before picking a slot. If a type should only be taken by certain members of the host pool, open Hosts on that type and tick them; leaving every box unticked means the whole pool is eligible, which is the default.

How do I verify a webhook really came from Atlas?

Every delivery carries an HMAC-SHA256 signature in the X-Atlas-Signature header, in the form sha256 followed by the hex digest, computed over the request body with the secret shown when you created the subscription. There are six attempts in total before a delivery is marked failed. Compute the same signature on your side and compare. That way you can trust the payload without the sender and receiver having to share a token through another channel.

Does a booking create anything in Atlas?

A page can create a task for each booking, which is on by default when you create a page through the interface. Turn it off if the bookings belong on your calendar but not in your task list.