A woman booked my smaller unit at 2:40 in the afternoon and was standing at the door by 4:15. Same-day booking, flight got in early, perfectly ordinary.
Her code did not exist. Not “didn’t work” — did not exist. The lock had never been told there was a reservation, because the thing that told the lock about reservations read my calendar every four hours, and the next read was at six.
I was in a parking lot two hundred miles away, and I had built this on purpose. I had a lock that could make codes on demand, a system that knew every booking I had, and a connection between them that I had described to a friend, three weeks earlier, as “fully automated.” All of that was true. It was also, for ninety minutes of that woman’s evening, completely useless, and not one part of it was broken.
The lock was fine. The booking data was fine. What failed was the integration — and the integration is the part nobody evaluates, because on every vendor’s website it’s a logo in a grid.
The Integration Is a Data Contract, Not a Logo
When a host asks whether a property management system “integrates with” their access control, the answer they get is yes or no. That’s not the useful question. Every one of these connections is a contract about three things, and the logo tells you nothing about any of them:
- Which fields cross the boundary. Dates? Times? The guest’s name? Their phone number?
- How fast they cross. On the event, or on a schedule?
- What happens when they change. A reservation is not a fact. It’s a fact that gets edited.
Two integrations that both claim “supports smart locks” can differ enormously on all three, and the difference only shows up on the day it costs you. The parking-lot evening was my education in field one and field two at once.
A door doesn’t need your calendar. It needs to know who can open it, between what two moments in local time, and the instant that changes. Most of what connects bookings to locks carries the first third of that.
What Access Control Actually Needs From a Reservation
Write out what the door needs, as fields, and then go look at what your current pipe carries. The gap is usually obvious once it’s a list:
| Field | What it’s for | Carried by a plain iCal feed? |
|---|---|---|
| Arrival date | Which day the code starts | Yes |
| Departure date | Which day it stops | Yes |
| Check-in time, local | So the code is live when they arrive, not at midnight | No |
| Checkout time, local | So it dies at 11am, not at an arbitrary hour | No |
| Guest name | So you can tell two codes apart later | Usually not |
| Guest phone / contact | So the code can be delivered without you | No |
| Reservation state | Cancelled, altered, pending — each should move the code | No |
| A stable reservation ID | So an edit updates the code instead of adding a second one | Sometimes, unreliably |
That table is the whole article, really. An iCal feed is a list of busy dates, which is exactly what it was designed to be and exactly why it’s a wonderful way to stop double bookings — I went through that in detail in the piece on choosing a calendar sync tool. It is a poor substrate for a door, because a door is a question about time of day and identity, and dates alone answer neither.
This is the reason I’d rather a tool read reservations from Airbnb and VRBO through a real connection than infer them from a calendar URL. Outkeepr pulls the actual reservation — guest, phone, arrival and departure as the platform knows them — which is what makes a code that starts at your real check-in time and a message that reaches the guest without you possible at all. Those aren’t separate features from the sync; they’re what you get once the right fields are on the wire.
The Four Shapes This Comes In
Nearly every host setup I’ve seen is one of these, and they fail in different places.
1. Calendar-driven. Something reads an iCal feed and creates codes from the dates. Cheap, universal, works with everything. It has the gap in the table above: no times, no identity, no delivery, and it finds out about changes whenever it next looks.
2. PMS-native lock support. Your management software talks to specific lock brands directly. When the pairing matches what you own, this is the best version of the setup — the reservation and the credential live in the same system, so there is no boundary to drift across. When it doesn’t match what you own, it’s a reason to replace hardware.
3. Lock-vendor-native PMS support. The lock company’s own platform ingests bookings. Same strength, same brittleness, from the other direction — and the booking side tends to be the thinner half, because a lock company’s core competence is locks.
4. Middleware. A hub in between that speaks many PMSs and many lock brands. It solves the pairing problem and adds a third vendor, a third subscription and a third place for a sync to be silently stuck. For a mixed portfolio it is sometimes the only option, and it is worth knowing that’s the trade you’re making.
There’s a fifth, which is a script you wrote against two APIs. I’ve done it. It works beautifully and it is load-bearing infrastructure maintained by a person who also has a day job, which is a sentence worth sitting with before you commit your arrivals to it.
Push or Poll Decides Whether Same-Day Bookings Work
This is the question I’d ask first now, and it has a clean test: book your own property for tonight, and time how long until the code exists.
A polled integration wakes up on a schedule and asks what changed. Whatever interval it uses is your worst-case delay on every arrival, and on same-day bookings — which are a meaningful share of bookings, more so in cities — that delay lands directly on a guest standing outside. A pushed integration is told the moment the reservation appears, and the code is there before the guest has left the airport.
Polling isn’t disqualifying. It’s a number you need to know, and most hosts have never been told it. If the answer is four hours, that’s a real constraint and you can design around it — a backup entry method, a code you can issue from your phone in thirty seconds, instructions that don’t assume the keypad.
The reason I care about this one disproportionately is that the failure is invisible for months. Every advance booking works perfectly. The system looks flawless right up to the first same-day arrival, which is also the guest least likely to have read anything you sent. If you want the mechanics of designing arrival for the case where the credential isn’t ready, that’s most of what automatic guest check-in is actually about.
Date-Only Data and the Bug You’ll Blame on the Lock
Here’s the subtle one. An iCal event for a stay is usually a date, not a timestamp. So anything building a code from it has to invent the hours, and it invents them in whatever timezone it happens to be thinking in.
The symptoms look like hardware faults and aren’t:
- A code that stops working the morning of checkout day, hours before checkout, because departure was treated as the start of that day.
- A code live the evening before arrival, which is harmless until the previous guest hasn’t left and your cleaner walks in on a stranger.
- A code that expires one hour early or late twice a year, when the clocks change in your property’s timezone but not in the server’s.
I chased the third one for an embarrassing length of time, convinced the lock’s firmware was drifting. It was a UTC offset, applied to a date that never had a time in it, for a property in a timezone nobody in the pipeline had been told about.
What makes this go away is the property’s own timezone and real check-in and checkout times being part of the property record, so a credential window is computed in the place the door physically is. It’s a dull thing to look for in software and it eliminates a whole genus of 7am phone calls. When a host sets up a home in Outkeepr, the arrival and departure times are part of the home, not a default buried in the integration — which is the difference between a code window that matches your house rules and one that matches a server’s idea of midnight.
The Vendor-Pair Trap
The practical version of this whole topic, for most hosts: you don’t get to choose your PMS and your locks independently, and you’ll discover the coupling after you’ve bought both.
What happens is that you pick management software for its calendar and its messaging, since that’s what you feel daily. Then you buy locks on a hardware judgement — this one takes AA batteries, that one survived a Vermont winter. Then you try to connect them and find the supported list is three brands, none of them yours.
Two honest ways out, and I’ve taken both:
- Standardise the hardware. Pick the lock your software supports and replace what you have. Costs money once, then stops costing anything.
- Accept the middleware. Keep both, pay a third vendor to translate, add a dependency.
What I’d avoid is the third option, which is to keep the locks manual and put a recurring task in your head. That’s not a setup, it’s a deferral, and it comes due at 11pm.
The lesson I took from doing this the expensive way is to check the pairing before buying either side. It’s also why Outkeepr connects to lock brands directly — Sifely and Wyze, where you sign in with your own lock account and set door codes from the reservation — rather than asking you to stand up a middleware layer to reach your own front door. The narrower list is the point: a connection that goes all the way to the hardware is worth more than a long grid of logos that each need a translator.
The Barriers With No API
Access control in a real property is rarely one deadbolt. It’s a community gate, a callbox, a garage, an elevator fob, a parking pass, and then the door. Integrations reach the door. They almost never reach anything else, and the gate is often the one that actually stops the guest.
The move that works is to stop expecting the integration to cover the whole path and instead make the un-automatable barriers into scheduled work and scheduled information:
- A gate code that rotates monthly becomes a recurring task that updates the instruction, not a thing you hope to remember.
- A callbox that dials a number becomes a number that always answers, chosen deliberately.
- A physical pass becomes a handoff designed on purpose, with a location and a confirmation.
None of that is an integration. All of it is the same discipline applied to barriers that don’t have a port to plug into, and I wrote the long version of it for gated communities, which is where this gets worst.
What Has to Happen When a Reservation Changes
An integration that only handles creation is handling the easy third. Reservations get extended, shortened, cancelled and rebooked, and each of those should move a credential:
- Extended. The code’s end moves out. If the system instead makes a second code, you now have two live credentials and one of them has no expiry anybody is tracking.
- Shortened or cancelled. The code dies now — not on the original departure date, which is the default behaviour of anything that cached the first version and never re-read it.
- Guest changed. New contact, new delivery, same window.
- Cleaning moved. The cleaner’s access should move with it, because cleaner access derived from a job expires when the job does.
That last point is the structural fix for all four. If credentials are derived from reservations and jobs rather than copied from them once, a change propagates because there’s nothing to propagate — the window is a function of data that already moved. If they’re copied, every change needs a human to remember, and the week you’re busy is the week with the most changes. That’s the argument I made at length about automating key exchange: issuing the code is the easy half.
It’s also the reason I keep cleanings, guest codes and staff assignments hanging off the reservation in Outkeepr rather than beside it. When a guest extends, the cleaning moves and the code window moves, because both were only ever expressions of dates that just changed. Nothing about that is clever — it’s just the alternative to a to-do list you maintain during the busiest week of your year.
The Failure Path Is Part of the Integration
Every integration in this category will be down at some point — the lock’s cloud, your software, the property’s wifi, the batteries. Treat that as a design input rather than an outage.
- Can you issue a code from your phone in under a minute, without the integration, from wherever you are?
- Is there a mechanical backup — a lockbox with a key, a second keypad — and does the guest know about it before they need it?
- Does someone get told when a code fails to write? A silent failure is worse than no automation, because you’ve stopped checking.
- Is there a human to call, and is their number in the arrival message rather than only in your phone?
The third bullet is the one I’d press a vendor hardest on. “We create the code automatically” and “we tell you when we couldn’t” are different promises, and only one of them lets you sleep.
How to Test an Integration in One Afternoon
Don’t evaluate this from a feature grid. Two hours on one property tells you more than a week of reading, and it’s the first thing I’d do with a trial on any tool — Outkeepr included, where connecting one home and one lock is the whole setup and you’ll know inside an afternoon whether the pipe carries what your door needs.
- Connect one property and one lock. Note how long it takes and how much of it you had to guess.
- Block tonight as a reservation. Start a stopwatch. How long until a code exists? That’s your same-day number.
- Check the window in the lock’s own app, not in the software’s summary. Confirm the start and end are the local times you expect, on the right days.
- Extend the booking by one night. Does the existing code’s end move, or does a second code appear?
- Cancel it. Does the code die now, or on the original departure date? Go look at the lock, not the dashboard.
- Take the lock offline — pull a battery, kill the wifi — and make a booking. Does anything tell you it failed?
- Check who got the code. Did the guest receive it without you doing anything, and at a sensible hour?
Steps four, five and six are where products separate. Step one is where they all look the same.
Questions to Ask Before You Buy
- Which lock and gate brands do you support, and does the connection reach the hardware or a middleware layer?
- Do you read reservations through a platform connection or from a calendar feed?
- Are codes created on the booking event, or on a schedule? What’s the interval?
- Where do check-in and checkout times and the property’s timezone come from?
- What happens to a code when a reservation is extended, shortened or cancelled?
- Do you notify me when writing a code fails?
- Can I issue and revoke a code manually, from my phone, right now?
- Can staff credentials come from the cleaning schedule rather than being standing codes?
Vague answers are answers. A vendor who has actually built this knows the polling interval off the top of their head.
The Short Version
- The integration is a data contract, not a logo. Ask which fields cross, how fast, and what happens on change.
- A calendar feed carries dates. A door needs times, identity and a way to reach the guest — so calendar-driven access control has a ceiling you’ll hit.
- Ask push or poll, and get the number. It’s your worst-case delay on every same-day arrival.
- Date-only data plus an invented timezone produces bugs that look exactly like broken hardware.
- Check the PMS-and-lock pairing before buying either. Standardise the hardware or accept middleware; don’t quietly go manual.
- Nothing integrates with the gate. Turn un-automatable barriers into scheduled tasks and scheduled information.
- Derive credentials from reservations and jobs so changes propagate without you.
- Test it in an afternoon — same-day booking, extend, cancel, offline. Watch the lock, not the dashboard.
That woman got in at 5:50, after I talked her through a lockbox I’d nearly removed two months earlier because the automation had made it redundant. She was gracious about it. She also mentioned it in her review, in the mild way that costs you a half-star and tells future guests the check-in is fiddly, and she was right — it was fiddly, in exactly one invisible place, four hours wide.
If you’d rather the pipe between your bookings and your doors carried the whole reservation, download Outkeepr — $5 per property per month plus 0.5% per booking, with 14 days free. Connect one home and one lock, then run the afternoon test above before you move anything else over. The integration you’ve verified is the only one you can plan around.
Ready to automate your vacation rental?
AI guest messaging, smart lock codes, cleaner scheduling, and more — starting at $5/mo per property.
Try Outkeepr Free