Can I keep using a lockbox if it is inside the building?

Rules generally target boxes on public facing surfaces such as street walls, railings and posts. A box inside a private lobby or on your own door is a different situation, but it is decided locally, so confirm the current rule for your address before relying on it.

What happens if the guest arrives before the smart lock code is issued?

Under this flow that cannot happen for a compliant booking, because the code is issued when the registry accepts the traveller record, which is normally well before arrival. If the record was never completed, the guest is blocked and your team is notified, which is the intended outcome rather than a fault.

Do I need a different lock for each property or can one system cover a portfolio?

One system covers the portfolio as long as every lock exposes an API for time boxed codes. Mixing vendors is workable because the automation talks to each API, but mixing vendors that do not all support offline codes creates two different failure modes to operate, which is the part that costs you.

Automate Vacation Rental Check In Without a Lockbox

Exterior lockboxes are being removed, not regulated

Across Spain, including Alicante, municipalities have moved against key boxes fixed to public facing walls, railings and lamp posts. The direction of travel is removal rather than permitting. Check the rule in force for your street before you plan around a box, because the answer changes by municipality and it changes fast.

The operational problem is unchanged either way. A guest lands at 23:40, the flight was late, and somebody has to open a door. Two models can do that. One costs a trip. The other costs nothing per arrival.

What replaces the lockbox

A smart lock (Nuki, Tedee or an equivalent with an API) plus a rule about when the code is issued. The lock is the cheap part. The rule is what makes the system hold.

The access grant is an output, not a step

Most installations fail here. They fit a lock, then keep issuing codes by hand from a calendar. That is the same trip converted into a message, and it still breaks when the guest arrives before anyone has sent it.

Make the code a consequence of the registry submission being accepted. If the traveller data has not been accepted, no code exists. Compliance stops being a task somebody remembers and becomes a precondition of entry.

Codes are scoped to the stay window

Issue the code valid from check-in to checkout, not indefinitely. A code that outlives the stay is a key you cannot get back. Time boxing is the part a physical key never had.

The four events that run an arrival

1. Booking confirmed

The channel webhook fires. That event creates the stay and sends a check-in link to the lead guest, one form per traveller. Starting at booking rather than at arrival is what buys you room when the booking is same day.

2. Traveller data captured and validated

Document number format, issuing country, and every mandatory field are checked while the guest is still filling the form. A rejection found nineteen hours later is a rejection you cannot act on.

3. Registry accepted

The submission goes to the authority and you store the acknowledgement with its timestamp. The acknowledgement is the evidence, not the send.

4. Access released

The accepted record triggers the lock. Code delivered by message and email, valid for the stay window.

What this changes in hours

A manual handover runs 45 to 90 minutes door to door once you count driving, parking and waiting for a guest whose flight moved. At three arrivals a week that is roughly 2.5 to 4.5 hours, every week, on a single property. The same three arrivals under the automated flow consume no field time at all. The work that remains is exception handling, which is a fraction of the volume.

The second saving is quieter. Nobody is on call for a 02:00 arrival, because 02:00 arrivals no longer require a person.

Failure modes and how the flow handles them

The guest arrives at 02:00

Nothing special happens. The code was issued when the registry accepted the record, hours or days earlier. Arrival time stopped being an operational input.

The lock loses connectivity

Pick a lock that supports offline codes, generated from a time based algorithm rather than fetched on demand. Then a dropped bridge is an inconvenience for your dashboard, not a guest standing outside. Verify this specific capability before buying: it is the difference between a lock and a liability.

The registry rejects the submission

No code is issued, and somebody gets a notification instead of a fine. This is the behaviour you want. A rejected submission means the stay is unreported, and an unreported stay should not be able to open a door.

A guest never completes the form

The chain stalls at step two and surfaces on your queue. Chase it at booking plus 24 hours, not at arrival, which is when you still have time to fix it.

Choosing the lock

Three questions decide it. Does it expose an API for issuing and revoking time boxed codes. Does it support offline codes. Does it fit the door you actually have, which in older Alicante buildings often means a euro cylinder with limited clearance.

Everything else (finish, app design, brand) is preference. Those three are the ones that determine whether the flow above can run at all.

What to do this week

Audit one property. Time the next three handovers honestly, door to door. Then check what your municipality currently says about exterior boxes. Those two numbers, your hours and your local rule, decide whether this is a project for this quarter or for next year.

Ecosystem & Connected Systems