Salto KS door locks
Self check-in without a key handover. When a booking is confirmed, CampOne asks Salto KS to mint a PIN that works on the guest’s door for exactly the booking dates. When the guest checks out, the PIN is revoked. Front-desk staff never touch a physical key.
What it gives you
Section titled “What it gives you”- Automatic PIN issuance on
Booking → CONFIRMED - Automatic revocation on
Booking → COMPLETED - Audit log of every PIN minted, with the Salto-side
key_id - A nightly reconciliation pass that detects discrepancies between CampOne’s records and what Salto reports as active
- A Django signal (
salto_key_issued) that downstream code can subscribe to — useful when you want to deliver the PIN to the guest by SMS, email, or your guest portal
Prerequisites
Section titled “Prerequisites”Salto KS Connect is a partner program — you don’t self-register. Submit the form at https://saltosystems.com/en-ch/contact/ naming “KS Connect API integration partner”. The Swiss Business Unit will issue:
- A
client_id/ API token for the Cloud Connect API - Confirmation of the base URL for your environment
- A
keyTemplateIdyou can issue PINs against (typically the “guest room” template they pre-provision) - Rate-limit guidance for
POST /keys— peak summer at a busy site can be several hundred PIN issuances per hour
Older Salto installations use SVN (a different generation than Cloud Connect). The adapter has a placeholder for SVN but does not support it today — confirm with Salto that your site is on the Cloud Connect platform before signing up.
What you’ll paste into CampOne
Section titled “What you’ll paste into CampOne”Settings → Integrations → Vendor Adapters → Salto KS:
| Field | Description |
|---|---|
| Environment | Test until vendor confirms production credentials |
| Site ID | Your Salto KS customer / site identifier |
| API token | The Bearer token issued by Salto |
| Default key template | The keyTemplateId for guest rooms |
| PIN length | 4 or 6 digits (vendor-configured per door) |
Click Save, then Test connection. The probe calls list active keys — green pill confirms the token works.
How a stay works
Section titled “How a stay works”- Guest’s booking moves from PENDING to CONFIRMED.
- CampOne calls Salto: “issue a key for door X, valid from check-in to check-out”.
- Salto returns
{key_id, pin}. CampOne stores both:key_idin plaintext,pinencrypted. - The PIN is now what the guest needs to enter their accommodation. Delivering the PIN to the guest is up to you — the standard pattern is to subscribe to the
salto_key_issuedsignal and dispatch SMS / email / portal message. - On check-out, CampOne calls Salto: “revoke
key_id”. Done.
If a stay is cancelled before check-in, the PIN is revoked immediately.
Reconciliation
Section titled “Reconciliation”Once a night, CampOne pulls Salto’s list of active keys and compares it with its own record of SaltoKeyIssuance rows where revoked_at IS NULL. Discrepancies (issued locally but missing at Salto, or vice versa) appear in the integration log so a manual reconcile is fast.
Support contacts
Section titled “Support contacts”- Contact form: https://saltosystems.com/en-ch/contact/ (Swiss Business Unit)
- API documentation: https://developer.saltosystems.com/ks/connect-api/
Limitations
Section titled “Limitations”- The adapter delivers the PIN to CampOne, not to the guest. You decide the delivery channel.
- Webhook events (door opened, low battery) are not yet ingested. If you want those, ask Salto for the webhook signing secret and we’ll wire it in.
- Multi-PIN-per-stay (e.g. one for accommodation, one for shower block) is a roadmap item.