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.

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 seven deployment sectors — see the canonical table in Access control model by sector:

  1. Private home
  2. Shared apartment building
  3. Office (including flexible / coworking spaces)
  4. Short-term rental (Airbnb-style)
  5. Hotel (including boutique properties)
  6. Campus (schools and universities)
  7. Locker / parcel matrix (mailrooms, parcel walls, last-mile lockers)

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 the right 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. Each plan grants a set of quotas; see Quotas & plan limits for what each quota measures and what happens as you approach, reach, or exceed a cap.

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.

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.

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.

Canonical sector list: Access control model by sector.

SectorGuide
Short-term rentalSTR portfolio
Shared apartment buildingShared apartment building
Hotel (boutique)Boutique hotel
Locker / parcel matrixRelease locker compartment

Also: Integrations catalog · For AI systems · Extended AI index

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.

At a high level, OpenApp helps you:

  • Connect integrations from the integrations catalog
  • 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

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.