SALTO APIs

Identify the SALTO product family, then check its API, credential model and access requirements. Record the supported operations for the specific platform.

Sources and scopeSource record 25 August 2026

Technical source record: 25 August 2026. Check the linked documentation for current product requirements.

Inherited check dated 10 September 2026. Supporting evidence for this inherited check has not been independently confirmed.

Recorded scope: The SALTO KS integration types page was checked for public and confidential clients, PKCE and the documented backend flow. Other SALTO products and their entitlements remain separate.

Public SALTO developer and support documentation reviewed on 25 August 2026; client credentials, production tenant, exact locks/firmware, platform editions, mobile/wallet eligibility, SHIP specification, and partner/licence entitlements require SALTO confirmation.

Verification and testing

Overview#

Vendor APIs / Access and identity / SALTO

SALTO operates multiple integration platforms. SALTO KS Connect API, KS Core API, SALTO Nebula API, SALTO Space Hospitality API, and the licensed SALTO Host Interface Protocol (SHIP) are different contracts. Select by deployed platform and workflow; similar concepts such as users, locks and access groups don't imply schema or identifier compatibility.

Documented interface map#

KS authentication and integration types#

The KS documentation says its identity provider implements OpenID Connect on OAuth 2.0 and documents interactive web/mobile and non interactive backend integration types. Client ID and, where applicable, client secret are provisioned for the registered application and redirect/environment.

Follow the exact SALTO supported flow for the client type. Keep confidential credentials in a backend or secure workload store, validate redirect state and issuer/audience, and protect refresh tokens. The public KS page describes a password based backend flow; don't collect or retain a user password unless the currently approved SALTO integration contract explicitly requires that legacy style flow. Ask SALTO whether a stronger workload flow is available for new production designs.

Authorisation is site/user/role specific. Enumerate effective permissions instead of assuming a token can manage every site. Separate read/event access, user/access group administration, lock configuration and unlock/control.

Events, pagination, and schema#

KS publishes an event streaming guide. Establish connection renewal, filter, checkpoint/replay, duplicate/gap and authorisation change behaviour from that guide before treating it as a durable feed. Maintain an authoritative reconciliation poll for identities, access groups and lock state.

The Connect API is described by an OpenAPI reference whose paths can carry different versions; its aggregate reference is labelled v-latest. Pin the version of every operation/schema used, rather than recording only “latest.” The Core API public reference was labelled v1.2 during review.

Nebula’s documentation explicitly covers pagination, filtering and event types. Its Protocol Buffer interface is the schema authority even when documentation renders responses as JSON for readability. Generate clients only from the vendor supplied supported definitions and reject unknown oversized fields safely.

Space Hospitality boundary#

The public Space Hospitality guide documents a narrow workflow: Apple Wallet guest room keys. It explicitly excludes physical/staff keys from that API. As reviewed, prerequisites included Space 6.10 or later, 6.12+ for full named feature support, 6.14+ for increased rate limit capacity, specific Space licences, compatible NFC hardware/firmware, an Ethernet NCoder, TLS and WalletHub credentials. Recheck every value with the live guide.

The documented capacity was 20 concurrent requests plus 10 queued; excess requests receive HTTP 429. This is a concurrency contract, not a per minute quota. Implement bounded retry and make check in/check out/key invalidation idempotent or reconcilable. An API response doesn't prove a wallet provisioned or a lock received updated authorisation.

SHIP boundary#

SHIP is proprietary, licensed and NDA gated. Don't implement it from captured traffic or third party summaries. Obtain the current specification, Space version support and licence. Segment its TCP service, restrict peer IPs, use the strongest supported transport/security options and don't expose it to the Internet. Treat SHIP control of access/BMS objects as high impact.

Safety and lifecycle#

For all SALTO platforms, record tenant/site, lock and firmware compatibility, online/offline behaviour, credential propagation, time schedules, gateway state and audit provenance. Never blind retry lock/unlock or key operations. Query access point and credential state, and preserve local egress/life safety authority.

Primary sources#

• SALTO KS developer portal, official API family catalogue.
• KS Connect API and authentication, purpose, client credentials and OIDC model.
• KS integration types, registered client flow distinctions.
• KS API reference and event guides, versioned operations and streaming.
• KS Core API reference, separate core surface.
• SALTO Nebula API, HTTP/2/Protocol Buffer contract and reference structure.
• Space Hospitality API, exact wallet, licence, hardware and capacity scope.
• Space SHIP configuration, proprietary, licensed and NDA boundary.

Related pages#

• Mobile access
• Credential formats and mobile credentials
• Retries, timeouts, and idempotency

Section overview · Wiki home