Connect a lock and give guests access

Attach a lock to a unit, let YStay issue a code for every confirmed reservation, and know exactly which channel carries it to the guest.

A connected lock changes arrival day: no key to hand over, no single code shared by every stay. YStay issues one code per reservation, valid only around that stay, and sends it to the guest. Once the lock is attached, there is nothing left to do.

Two settings, in two different places. The provider is connected once for the whole account, from API & integrations. The lock is attached to a unit — one lock, one door: every listing sitting on that unit shares it. That second setting is the one that drives code issuance.

The path, screen by screen

Look at the available providers
In the Account group of the menu, open API & integrations. The Connected locks card states its purpose: “Connect your lock provider to automatically generate guest access codes at confirmation.”
Four rows, always the same ones. Virtual lock carries the Active by default badge and a Test connection button. Nuki offers Connect, which opens a Nuki API token field — the token is checked against Nuki before it is saved, and “The token is encrypted and will never be shown again.” Yale Home and SwitchBot carry the Coming soon badge: their button is disabled, and those providers cannot be connected today.
The Connected locks card on the Integrations page: the four providers and their state.
This page is not for everyone on the account
If the account is shared, the card shows “Only an account administrator can connect or disconnect a provider.” and hides the buttons of the real providers. The screen is not frozen for all that: the Test connection button on the Virtual lock row stays clickable, and ends on an error message. And you have to reach the page first: the API & integrations entry requires the billing permission, which the Manager role does not have — depending on the role, it does not even appear in the menu. Attaching a lock to a unit, on the other hand, stays open to the members who have write access on that property: a Read only role, or a property scope that excludes this one, is refused just the same.
Open the listing's Connected lock card
Open the listing page and scroll to the Connected lock card. It spells out the commitment: “Attach this property's lock: guest access codes will be issued automatically when each reservation is confirmed.”
As long as no lock is attached, the card shows No lock attached. and the consequence: “Without a lock, no automatic access code is issued for this property.” The Manage providers link goes back to the previous screen.
The Connected lock card of a listing with no lock: the empty state and the Add a lock button.
These cards say “property” where this guide says “unit”
The lock screens use the word “property” for what you actually rent out — the same object the rest of YStay calls a unit. There is only one thing here: the unit the listing sits on.
Fill in the add form
Add a lock opens two fields. Lock name is free text — the E.g. Front door hint says what is expected: the name of the door, not the name of the unit. Provider only lists providers that are connected and not gated; on a new account, that means Virtual lock is the only option.
For a real provider, YStay queries your account and shows Locks in your Nuki account: each lock carries Available, or Assigned to followed by the unit already using it — in which case it cannot be selected. If the provider does not answer, or has nothing to list, a manual identifier field takes over. Attach submits.
The add form: lock name and provider choice.
Check the attached lock
The lock appears in a list with its name, its provider and a status badge: Active, Inactive or Unreachable. Three buttons follow it: Test — which really calls the provider and answers Connection OK or Lock unreachable — Edit and Detach.
The attached lock: name, provider and status badge.
One lock per unit, in practice
Nothing stops you attaching two, but code issuance takes the first active lock it finds — a duplicate therefore creates a door nobody thinks about. Detach before you attach something else.
Let confirmation do the work
Nothing to trigger: when a reservation is confirmed, YStay issues the code in the background and writes it to the lock. The Property access card on the stay page — or on the reservation page — shows the result. Before anything is issued, it reads No active access code.
A reservation that is not confirmed yet has no stay, and the screen says so: “Confirm the reservation to create the stay and unlock operations (access, check-in/out, proof).”
The Property access card of a stay, before any code has been issued.
The Attach a lock button on this card opens no form
Attach a lock, here, immediately creates a virtual lock named Main lock — no provider choice, no confirmation, and a second one if you click twice. It is a workaround, not the normal path: go through the listing's Connected lock card, described above.
View, reissue or revoke the code
Once a code is issued, the card shows the Code generated: banner followed by the code and the words (shown only once). The code's row stays behind: a status badge — Active, Issued · sending at D-2, Issued · guest notified, Revoked, Expired, Revocation failed — and its window, Valid from … to ….
On an active code, View code shows it again in clear, with the warning (view is logged): every viewing is recorded. Revoke asks for a reason, then has the provider remove the code — it is the provider that deletes it from the lock, not YStay. Once it answers, the row reads Revoked and the guest can no longer open the door with that code. Generate an access code issues one on demand, for instance after a revocation.
If the provider refuses or does not answer, the revocation is not settled: the row reads Revocation failed and shows “Revocation with the provider failed: automatic retry in progress, the code may still work on the door.” A retry leaves on its own and you are warned by notification, but as long as the row does not read Revoked, assume the code still opens.
One last badge, at the top of the card, sums up the state of the access session. It is not translated: it shows in raw English, “active”. That is a known interface defect, with no consequence for the codes.
The Code generated banner, shown only once, and the active code line with its validity window.

The validity window

A code is never permanently valid. Its window opens 3 hours before the arrival time and closes on departure, at the end of the check-out window. Without house rules on the listing, YStay falls back to 16:00 for arrival and 11:00 for departure, in the property's time zone. That window is what the code's row summarises with Valid from … to ….

What the guest receives

The channel for the code is email, and email only. The message is titled “Your access code for your stay”; it carries the code — “Here is your access code: …” — and its expiry, “Valid until ….” It is sent in the guest's own language.

Alongside it, if the guest uses the app, a Your access is ready notification lets them know — but it does not contain the code: it only says “Your access code has been sent to you by email.” The code appears nowhere in the guest app, and YStay sends no SMS.

When arrival is still far off, the code is issued but delivery waits: the row announces “Sent automatically to the guest 48 h before arrival.” and the badge reads Issued · sending at D-2. On the day, the email goes out and a Your arrival is coming up notification reminds the guest where to find it.

If no code shows up

No active lock on the unit. The screen answers “No active lock: attach a lock first.” — that same message is shown whatever the real cause, so always check this point first.
The reservation is not confirmed. No stay, no access: confirm it first.
The stay is cancelled. No code can be issued on a cancelled stay any more, and existing codes have been revoked.
An active code already exists. Automatic issuance never duplicates a live code.
The listing requires an insurance certificate and none has been accepted for the arrival period: issuance stays on hold until one is.
The provider did not answer. YStay warns you with a notification, and manual issuance stays available from the stay page.

Receive your first reservation and manage your calendar — the path that takes a reservation through to confirmation.
Create and publish your first guidebook — the practical information your guest reads on arrival.
Listings — the other cards on the listing page.
Insurance certificates: accept, reject, unblock access — the decision that holds back, or releases, the door code.
Inspections: policy, guest link, templates — record the state of the unit on either side of that access.

Updated on 27 August 2026

Connect a lock and give guests access

The path, screen by screen

Look at the available providers

Open the listing's Connected lock card

Fill in the add form

Check the attached lock

Let confirmation do the work

View, reissue or revoke the code

The validity window

What the guest receives

If no code shows up

Next