Booking Software Door CodesHow a reservation turns into a door code that expires on time.
When a booking is confirmed and paid, the software generates a numeric code, sends it to the access controller with a start and end time, and delivers it to the customer. The controller — not the software — enforces the window, so the code opens the door from a few minutes before the session until it ends, then stops working on its own.
- Trigger
- Payment confirmed + waiver signed
- Sent to
- Your access controller, via its API
- Valid
- Reservation window plus a short grace period
- Delivered by
- Confirmation screen, email, calendar invite, and SMS
- Revoked when
- The booking is cancelled or refunded
How it goes together.
- 1
The customer pays and signs
The booking isn't confirmed until payment clears and the waiver is signed. Nothing reaches the door before both are true.
- 2
The system generates a code
A numeric PIN unique to that reservation is created — not a shared facility code, and not one that gets reused next week.
- 3
The code is pushed to the controller
The access controller receives the PIN along with the door it applies to and the exact start and end times it should be valid.
- 4
The customer receives it four ways
Confirmation screen, confirmation email, a calendar invite carrying the code in the event, and a text message if texting is enabled. The calendar invite matters most — it puts the code on a lock screen at session time without needing signal at the door.
- 5
The window opens and closes
The code works from a few minutes before the session until it ends, then expires at the controller. Nobody has to remember to remove it.
- 6
Changes propagate
A reschedule reissues the code for the new window. A cancellation or refund revokes it immediately.
What does the access controller have to support?
It needs an API that can create a credential — a PIN or card — assign it to a person or door, and set a validity window. Most cloud-managed commercial access controllers expose exactly that, because it's the same capability their own web dashboard uses.
Cinch issues the code. Delivering it to your specific door controller is integration work we scope and confirm before you sign — not a checkbox we pretend is already ticked. Most cloud access controllers (infinias / 3xLOGIC, and others in that class) publish an API for doors, people, and PIN credentials, which is all a per-session code needs. If yours doesn't, we'll tell you that on the first call rather than after the contract.
What if the controller can't set an expiry?
Then the software has to create the credential at the start of the window and delete it at the end, which works but depends on a scheduled job running reliably. It's a workable fallback, and it's worth knowing which of the two you're getting before you sign, because the failure modes are different.
Why not just use one code for everyone?
A shared code can't be revoked without telling everyone, can't tell you who was in the building, and never expires — so it accumulates every former customer and lapsed member you've ever had. A per-reservation code makes access an automatic consequence of paying, and non-access an automatic consequence of not.
What happens when the internet at the facility goes down?
Codes that were already pushed to the controller keep working, because the controller holds them locally and enforces the schedule itself. What stops is issuing NEW codes for bookings made during the outage — which is why the code is pushed at booking time rather than at arrival time.
Asked and answered.
How long before the session does the code start working?+
Can a customer reuse an old code?+
Can staff open the door remotely?+
One system. Booking, payment, waiver, door.
$249/mo flat, every feature included, no transaction fees and no contract. Free migration from whatever you run today.