Skip to content
OAOpenAppPhysical Security as a Service
Login

About OpenApp

OpenApp is physical security as a service: it connects to access control hardware and automation systems, normalizes them into a consistent model, and exposes them through a single platform.

Value proposition

Section titled “Value proposition”

OpenApp targets enterprise-grade reliability and capabilities while supporting a wide range of hardware, including very low-cost devices, so you can reduce capital and per-door spend where it makes sense—without sacrificing security or a strong user experience for residents, staff, and operators. OpenApp is built to the highest security standards expected of both physical access control and security SaaS, including encrypted communications between devices and the cloud.

Hardware and software are decoupled: you choose the integrations and devices that fit each opening, building, and budget; OpenApp stays the consistent control plane, APIs, and UX layer. Modularity means you assemble the pieces you need (integrations, zones, access rules, org structure) rather than buying a monolithic stack you cannot tune.

The same platform supports many deployment shapes, including private homes, shared apartment buildings, traditional offices, flexible or coworking spaces (WeWork-style), hotels, short-term rentals (Airbnb-style), and campuses (schools and universities). It is built to manage distributed sites—multiple buildings or regions—under clear organizational boundaries.

At the door, OpenApp supports virtual intercom flows: signage (QR, NFC tap, or short link) opens a mobile-friendly directory so visitors can call, message, or request unlock subject to policy—without a legacy lobby panel. The same model covers vehicle lanes and gates when operators link PalGate or other opener integrations.

Pricing follows a usage-based subscription: you pay in proportion to scale (for example number of doors and related usage), so costs tend to grow linearly with what you deploy instead of large upfront bundles that do not match real occupancy.

Automation and integration

Section titled “Automation and integration”

You are not limited to the OpenApp UI. The same platform is exposed through official SDKs, a public HTTP API, and OpenApp Scripting—OpenApp’s scriptable surface (internally a DSL, a domain-specific language)—so you can automate operations and integrate systems you already use—for example a property management system (PMS), a booking or guest stack, or internal tools—without re-keying every workflow in the dashboard.

SDKs

Section titled “SDKs”

OpenApp provides official SDKs that wrap the public API with typed models and shared client behavior (authentication, retries, and telemetry). Python is available today; other languages are on the roadmap—see the SDK overview for status and links.

API-first

Section titled “API-first”

OpenApp is API-first: the HTTP contract is the source of truth for what the product can do, and the dashboard consumes the same capabilities.

Scripting

Section titled “Scripting”

OpenApp Scripting is OpenApp’s automation language, based on the Rhai scripting language. It is implemented as a DSL (domain-specific language) for OpenApp workflows, and is suited for provisioning, bulk changes, and repeatable automation (creating or updating orgs, integrations, devices, entities, zones, and users from files or CI). See the OpenApp Scripting reference for syntax, the CLI, and the interactive shell—alongside one-off API calls and SDK code.

What the product does

Section titled “What the product does”

At a high level, OpenApp helps you:

  • Connect integrations (Home Assistant, KNX, MQTT, Shelly, PalGate, etc.)
  • Model devices and entities consistently across vendors
  • Organize entities into zones (rooms/areas/floors) when applicable
  • Control and observe through a unified interface and APIs
  • Apply access controls via orgs, users, and roles

Object model

Section titled “Object model”

Those capabilities map onto organizations, integrations, devices, entities, zones, users, and roles in the API and dashboard. How they connect—including ownership and provider mapping—is covered in Resource hierarchy; the Reference hub has one short page per resource with API entry points.