Configure the Salto connection, delivery channels and unit mappings.
Setup order
Open Salto and follow Onboarding when required settings are missing; reopen it later to review setup.
Connect with a dedicated Salto KS admin user and review the connection status.
Before assigning live users to access categories, review Automatic and the PIN replacement settings in the onboarding PIN rules step or the account-level Rules view. If existing codes must stay unchanged during setup, save Automatic off for the categories being configured.
Configure email sender settings or the required SMS provider settings for PIN delivery.
Pull sites/users and map the intended Apaleo properties and units.
Check the saved mappings and real property layout before marking mappings ready. Test the intended reservation workflow before turning Automatic on.
Salto KS remains the system for lock hardware, site users and physical access configuration. Required sites must already exist there.
Mappings ready is a setup status, not an automation switch. Reservation events can be processed as soon as a user is mapped to an automatic category; leaving onboarding unfinished does not pause PIN changes.
Preserve existing codes during setup
Connecting credentials and pulling sites/users do not change guest keypad PINs. Reuse the intended existing users and check their current Salto access groups.
Keep Automatic off while checking live mappings if the existing codes must remain unchanged. The default Accommodation unit rule is already automatic and can generate or replace PINs.
Use read-only PIN and guest-page checks to inspect recorded access. Use Generate PIN or Set custom only when you intend to change the real user PIN.
Review IQ activation separately from PIN automation. IQ setup uses its own credentials; the final IQ enable operation changes the app’s remote-opening policy.
Verify the actual property’s users, door grants, schedules and IQ state before enabling remote opening or reservation automation.
The wiki and support helper describe the product; they cannot confirm a property’s live Salto configuration or whether its existing PIN records match the locks.
Access contexts
Open from a reservation for that reservation’s PIN and guest access.
Use a permitted property context for property-scoped workflows.
Use an authorized account context for settings that affect several properties, API credentials and guest-access setup.
If a control is read-only, follow its account-context or administrator guidance.
Match the exact assigned unit with the correct site, access user and category.
Review the mapping
Open Mapping and pull the available Salto KS sites and site users.
Choose the site, property and exact Apaleo unit for each mapping.
Review the access category and other mapping controls offered for the user.
If a needed user is missing, use the supported push/create-user flow in an existing Salto site.
Wait for the mapping save indicator after edits, then reopen or refresh to verify the saved values.
Mapping edits auto-save. Unit names can be similar; reservation PIN lookup relies on the unit ID.
Check a changed unit assignment
Open the reservation and verify its current assigned unit.
Find the mapping for that exact unit and confirm the correct Salto site/user.
Review rules and the current PIN record before generating or sending new access.
Reuse existing room users
An existing Salto user named after a room number can continue to be used. Select that existing site/user and map it to the exact Apaleo property and unit.
Room-number names are labels; the saved Salto site/user IDs and Apaleo unit ID determine the mapping. Matching names alone do not create it.
Keep the existing Salto access groups when they already grant the intended room and exterior doors. Mapping a user does not replace those groups.
Pulling users does not import or verify the current keypad PIN. Current PIN shows the app’s recorded value; an empty value does not prove the real Salto user has no working code.
Review Automatic before choosing an access category. Saving the mapping does not itself change the Salto PIN, but subsequent reservation events can do so under that category’s rules.
Choose when each category assigns, rotates and releases access.
Default PIN behavior
Accommodation unit defaults to Enabled, Automatic and Unique to reservation. Its assignment event is Unit assigned; Generate a fresh PIN when access is assigned is off, and Replace the old PIN when access is released is on.
Assignment reuses the locally recorded user PIN when possible. A missing PIN or a PIN already used by another unique reservation causes a new PIN to be generated even when fresh-PIN-on-assignment is off.
The default release events include checkout, no-show, unit unassignment, cancellation and deletion. A room move can release the old unit’s access and replace its PIN.
Other common area and Public entrance default to shared PINs with Automatic and both PIN replacement options off. Review saved rules because they can override defaults.
Mappings ready does not gate reservation processing. To pause event-driven PIN changes while preserving read access, save Automatic off before assigning live users to the category.
Configure a category
Open Rules in an authorized account context and select the category and property scope.
Review whether the category is enabled and whether Automatic should process reservation events.
Choose assignment and release events for that category.
Review Unique to reservation, Generate a fresh PIN when access is assigned and Replace the old PIN when access is released.
Add a custom category only when it represents a real access policy and map the appropriate users to it.
Save the rules, then test the intended event sequence and inspect the reservation PIN record.
Property-context rules can be read-only because a rule can affect several properties. Unique, rotate-on-assignment and rotate-on-release are separate settings.
Check reservation eligibility, unit mapping and stay dates before changing access.
Work with a reservation
Open the Reservation view with the intended reservation/booking context.
Verify reservation ID, property, status, arrival/departure and assigned unit.
Review the matching site/user/category and any eligibility message.
Use Generate PIN or, where supported, Set custom when permitted and appropriate for the property’s PIN policy. Reservation changes require an in-house stay or a confirmed arrival today.
Inspect the saved result and access dates before sending instructions.
Assign a unit in Apaleo first if there is no unit. A missing mapping must be corrected in Mapping; a PIN change cannot correct a wrong unit assignment.
Change a user PIN from Mapping
Open Mapping, select the correct site and find the existing Salto user for the room or shared entrance.
Review Access PIN → Current PIN and the user’s mapped property, unit and access category.
Choose Generate PIN to create and save a new PIN for that Salto user. Where the site has Salto Pro support, enter the intended value under New or custom PIN and choose Set custom PIN.
Check the saved result and any active reservation before delivering the replacement code. A user-level change affects that user’s PIN wherever its Salto permissions allow PIN access.
If the result reports an activation or save failure, inspect and reconcile the current state before retrying; Salto may already have changed the code.
Generate PIN changes the real code; it is not a refresh or synchronization button. Reading PINs, pulling users and refreshing a guest page do not rotate them. For an out-of-date code, check the mapping, PIN record and recent events before generating a replacement.
Create, use and revoke reservation-scoped links with PIN and remote-opening controls.
Create and revoke links
Open the reservation guest-access panel, or account-level API & guest access and enter the Apaleo reservation ID.
Load guest access and review the reservation and assigned unit.
Create the personal guest link, then inspect its validity and supported language.
Share it with the intended guest. To stop that link, use Revoke link and check the updated state.
Replace access after a unit or guest change
After a room move, verify the current exact Apaleo unit and its Salto site/user mapping, then create and test a new guest link before sending corrected instructions.
An existing link remains bound to its original unit/site/user; it does not become a link to the new unit after reassignment.
Check the old unit’s release result and configured PIN-rotation rule separately. An invalid old link does not prove that a previously known physical PIN changed.
For two people sharing one reservation, links can be revoked separately but they resolve to the same mapped user/PIN. Revoking one link does not independently revoke a PIN that person already knows; rotating that PIN affects other users of the same code.
Guest use
The guest opens the personal page and reviews the available PIN and doors.
Swipe-to-open sends an internet remote-opening request through the IQ. The guest’s phone needs internet access and can be away from the lock; this app does not provision Bluetooth mobile or digital keys.
Use a door’s swipe-to-open control only when it is offered and valid for the reservation.
If access is unavailable, check the stay window, reservation status, assigned unit, link validity and IQ remote-opening setup.
A valid link does not override reservation eligibility or physical lock configuration. Revoking a link and rotating a door PIN are different actions.
Access window, language and expiry
Links can be created in advance for a confirmed stay with a mapped unit and enabled rule. A future-arrival page shows upcoming without a PIN or doors.
In-house stays have access immediately, including an early check-in. Confirmed stays are eligible on their arrival day using the arrival timestamp’s offset; a missed arrival day requires check-in.
Canceled, checked-out, expired, moved, remapped or revoked access is denied. If a stay extends past the link’s original departure expiry, create a new link.
Use the language picker when creating the link or change its lang parameter for presentation. Unsupported/missing language codes use English.
For opening, swipe right and release; keyboard users can focus and activate the handle. A successful response confirms an opening request, not a door sensor reading.
Guest reads do not generate or rotate PINs. Door availability is rechecked against current mappings, access-group schedules, hardware and IQ settings.
Choose which shared entrance doors appear for guests of mapped units.
Keep existing access groups or use separate entrance users
Salto KS access groups continue to determine which locks each mapped user can access. If the existing room user already has rights to several exterior doors, those grants can continue to supply the app’s available doors.
Separate Public entrance users are optional for an existing room-user/access-group setup. Use them when guests should receive a distinct shared entrance PIN or a named entrance access set.
For example, three exterior doors can share one entrance user when its Salto groups grant all three, or use several entrance users with their own PINs and grants. Verify the real layout in Salto KS.
App entrance rules and IQ controls can restrict which granted doors are offered for remote opening. A door also needs an active group schedule, valid user access, an online lock/IQ and the required remote-opening setup.
The same PIN works across doors only where that PIN’s Salto user has the corresponding access. Selecting doors in the app cannot grant additional Salto rights.
Configure separate shared entrance access
In Mapping, choose Public entrance for the relevant Salto user, select its property and enter the guest-facing entrance name. Public entrances have no unit assignment; Other common area remains a separate category.
Open API & guest access → Main entrance access and choose the Apaleo property and Salto site.
Select the actual entrance doors from that site.
Choose all eligible mapped units, selected mapped units, or no units to hide those doors.
Use Swipe to open the main entrance to control remote opening. Turning it off keeps entrance PINs visible while disabling entrance swipes; room swipes remain separate.
Remove unavailable stale door selections, save, and test a guest link for an included and an excluded unit.
There is one Main entrance access rule per account, live/test mode, Apaleo property and Salto site. Its unit list applies to every explicit Public entrance user in that property/site. Saving another door/unit selection in the same scope replaces that rule; it does not add a separate per-door rule.
Included units can receive all stored Public entrance PIN entries in that property/site. Selecting only some doors or disabling swipes does not filter those PIN entries. Do not use separate property entrance users to distribute restricted stairwell or laundry PINs to different apartment groups in one site; independent per-entrance unit lists are not supported.
For an own-stairwell or paired-stairwell arrangement, keep each apartment user mapped to its exact unit and grant the intended doors through that user’s Salto KS access groups. Users in a paired stairwell can have both doors; laundry access belongs only to the authorized users. The app does not infer access from building names or proximity.
Entrance rules filter existing Salto grants; saving does not open doors or change Salto users, PINs, groups or IQ settings.
Guest pages show named entrance access sets and Your room separately, keeping each PIN with its own doors.
Follow the IQ selection, setup PIN, activation and review flow.
Remote opening and mobile keys
This app sends a server-side internet command to the selected lock through Salto KS and its IQ. The guest’s phone needs internet access, but does not need Bluetooth or proximity to the lock.
The lock and IQ must be online, and current user grants, group schedules, reservation eligibility and the app’s IQ/entrance settings must allow the opening.
This integration does not issue Bluetooth mobile or digital keys. A mobile key managed separately in Salto KS is a different access method; its rights do not establish that an app remote-opening request is available.
Enable remote opening
Open API & guest access → IQ remote opening and load/search the relevant IQs.
Select the intended IQs and continue to setup.
For an IQ not yet activated for the connected Salto account, choose email or SMS for its setup PIN when offered and complete the displayed PIN/activation verification steps.
For an already activated IQ, use Connect activated IQ with the current four-digit IQ PIN and fresh code from the Salto app. Keep using the same connected account; do not reset the IQ or start a new activation to replace a working one.
Review the exact IQs and the enable operation, then apply and check the final result.
What IQ setup changes
The IQ setup PIN and activation credentials secure remote opening for the connected Salto account. They are separate from the room or entrance user’s guest keypad PIN.
IQ setup does not change guest keypad PINs or mapped users’ Salto roles and access groups. The final reviewed enable/disable operation saves this app’s IQ access policy and does not open a door.
Explicitly enabling an IQ can let mapped PIN-only users use guest remote opening without granting them a Salto mobile-user role. Their existing groups, schedules and reservation checks still apply, and the connected integration needs permission to open the lock.
Turning an IQ off stops remote opening through this app. Other IQ selections and normal Salto keypad access remain separate.
If an activation was already completed elsewhere, connect the existing activation. Reactivating the same connected identity elsewhere can invalidate saved IQ credentials; inspect activation status before retrying an interrupted setup.
IQ setup does not pause reservation PIN automation. Review Automatic and the replacement settings separately when preserving existing guest codes.
Turn off or troubleshoot
Select enabled IQs and review turning off before applying it.
If a request stalls, use Stop waiting and inspect the reported state before restarting.
Check Salto credentials, IQ availability and activation status when remote door opening is unavailable.
IQ setup PINs and activation codes are credentials. Enter them only in the setup UI, not in support chat.
Grant only the read, PIN-write, guest-link or door-open capabilities an integration needs.
Manage integration keys
Open API & guest access in an authorized account context.
Name the integration and choose its permissions: Read PINs, Generate and set PINs, Manage guest links and/or Open doors.
Create the key and copy the full credential immediately into a server-side secret manager.
Review the key prefix, permissions and expiry in the list.
Revoke a key when retiring or replacing it.
The public wiki API does not grant any Salto operational permissions. Salto operational APIs require their own credentials and access checks.
PIN and guest-link endpoints
Send Authorization: Bearer YOUR_API_KEY from your backend. Keys expire after one year and cannot read configuration or provider credentials.
Use GET /api/salto/reservation-pin?accountCode=ACCOUNT&reservationId=RESERVATION with pin:read to read eligible reservation PINs. Reads do not generate a PIN.
Add &includeEntrances=true to that GET to include explicitly mapped property entrance PINs. The response contains pin, testMode and entrances: an array of {id, name, pin, swipeEnabled}. These entries represent entrance users/access sets, so three physical doors do not necessarily mean three PIN entries.
Use PUT /api/salto/pin-mutation?accountCode=ACCOUNT with pin:write and mode (generate or custom), siteId, userId, reservationId, propertyId and unitId for a reservation change. For custom mode, also provide pin. User-level changes can omit reservationId, propertyId and unitId, but still require an existing user mapping and cannot create or change mappings.
With guest:manage, use POST or GET /api/salto/guest-links?accountCode=ACCOUNT&reservationId=RESERVATION to create/list links; DELETE with {"id":"LINK_ID"} revokes one. POST can include {"language":"fi"}.
Keys share a 120-request/minute budget. Opening attempts are additionally limited; respect Retry-After. Do not automatically retry a door-opening command.
Operational responses can be 401/403 for credentials/access, 409 for unavailable access or hardware/setup, 429 for limits and 502/503 for upstream/storage failure. Investigate uncertain writes before retrying.
List doors and request an opening
With door:open, call GET /api/salto/open?accountCode=ACCOUNT&reservationId=RESERVATION. It returns {ok, doors: [{id, name}], testMode}; it does not return PINs or an accessId field.
POST to the same URL with {"doorId":"DOOR_ID"} to request opening one of the currently allowed doors. An API-key caller can omit accessId; the server resolves an eligible room or entrance source.
An optional accessId selects a specific access set. Use an entrance id from the includeEntrances PIN response, or an accesses[].id from the guest access response when using a guest link. Do not substitute a door ID or invent an access-set ID.
The guest-facing GET /api/salto/guest/pin and POST /api/salto/guest/open use the personal guest-link bearer token. The guest response includes accesses with id, kind, name, pin and doors; the opening body can include doorId and accessId. Keep account API keys on your backend.
An opening request is checked against the current stay, mappings, Salto groups and schedules, IQ policy and lock/IQ availability. Success means the command was sent; it does not confirm the physical door position.
GET /api/salto/reservation-pin?accountCode=ACCOUNT&reservationId=RESERVATION&includeEntrances=true
GET /api/salto/open?accountCode=ACCOUNT&reservationId=RESERVATION
POST /api/salto/open?accountCode=ACCOUNT&reservationId=RESERVATION
{"doorId":"DOOR_ID"}