How does booking software prevent double bookings?
Booking software prevents double bookings by making the availability check and the booking one step: it locks the slot, counts what's taken, writes the booking and only then lets the next request in. Holds keep a place for a few minutes and expire on their own, and idempotency keys stop a retried request from booking twice.
Updated
Why double bookings happen
- Two guests reach for the last seat at the same moment, and both see it free.
- A channel sells from a copy of your calendar that's minutes out of date.
- A request times out, the app retries, and the first try had gone through after all.
Each one is a race between reading availability and writing the booking.
Lock, check, write
The fix is to make the check and the write a single step. The system locks whatever is being sold (a session, a time slot, a pool of rental gear), counts what's confirmed and held, writes the booking if it fits and releases the lock. A second request waits its turn, then finds the place gone.
When that happens inside the database, in one transaction, no channel can skip the check.
Holds that expire
A hold keeps a place for a few minutes while a guest pays or an assistant confirms the details. It counts against capacity like a booking, so nobody else can take the place in the meantime.
A good hold expires on its own: when time's up the place is free again, with no clean-up job to forget. A late confirmation goes through only if the place is still free.
Idempotency keys
Networks drop responses, and apps retry. An idempotency key is a unique ID the client sends with each booking. If the same key arrives twice, the server returns the first booking instead of making another. If the key comes back with a different request, the server refuses it rather than guess.
Why it matters on mobile and at the last minute
Guests book late, and on their phones. 46.5% of leisure activity bookings are made 0–3 days ahead (GetYourGuide, Nov 2025), and 76% of FareHarbor bookings happen on mobile (FareHarbor, Jan 2026). Late bookings crowd onto the last few places, which is exactly where two requests collide.
Channels add more buyers for the same seats: OTAs took 37% of operator bookings in 2025 (Arival, Jan 2026).
How daybag does it
- One database function makes every booking: it locks the offering, checks capacity and writes the booking in one transaction. The dashboard, website widget, hosted booking page, API and MCP all go through it.
- Holds count against capacity until they expire. A guest paying online is held while they pay, and the booking confirms when the payment lands.
- Open holds are capped per guest and per API client, so no one can tie up your availability.
bookings.createtakes anidempotency_key: a retry returns the same booking, and a different request with the same key is refused.
The same check guards seats on a rafting trip, a guide's slots on a guided trip and rental gear. The details are in the API docs and on Developers.
Questions
What causes double bookings?
Two requests reading the same free place before either writes, a channel selling from out-of-date availability, or a retried request that had already gone through.
How long should a booking hold last?
Long enough to pay or confirm, short enough not to block other guests. daybag holds a place for 35 minutes while a guest pays online; holds made through the API can last from 5 minutes to 24 hours.
What is an idempotency key?
A unique ID sent with a booking request. If the request is repeated, the server returns the original booking instead of creating a second one.
Does daybag stop double bookings from every channel?
Every booking made in daybag, from the dashboard, widget, booking page, API or MCP, passes the same capacity check. Bookings taken in another system count once they're entered in daybag.