Integrations

Integrations are how OpenApp connects to access control hardware, automation systems, and protocols while keeping the core product consistent.

Solution architect? Start with architecture

If you are deciding deployment patterns (connectivity, scale, fallback, and security), read Choosing access control architecture first, then use this section to pick concrete providers.

Why integrations exist

Physical security is an ecosystem: different vendors, different deployment models, and different APIs. Integrations let OpenApp:

• Connect to vendor/protocol specifics without locking the rest of the product to any one system
• Evolve support over time as vendors change firmware, APIs, and capabilities
• Provide a consistent model for devices, entities, and actions across providers

Why modularity matters

Modularity keeps the platform maintainable and safe:

• Isolation: provider-specific logic is contained so changes don’t ripple through unrelated parts of the system
• Extensibility: new providers can be added without redesigning the core data model
• Operational clarity: support, debugging, and upgrades can be scoped to an integration

If you are still deciding which hardware or network architecture fits—single door vs many, Wi‑Fi vs wired vs cellular, budget vs vendor cloud—see Choosing access control architecture.

Request a new integration

Need a provider we don’t support yet? Get in touch and include:

• Vendor/product + model(s)
• How it connects (cloud, LAN, protocol like MQTT/KNX, etc.)
• Links to vendor docs and any existing open-source integrations (e.g. Home Assistant)
• Example payloads, identifiers, and expected actions (open/close/toggle, etc.)

Canonical integration list

This page and the grid below are the only place that enumerates supported providers. Elsewhere in the docs we link here instead of repeating vendor names — popularity in the market and depth of OpenApp support are not the same thing, and both change over time.

Support maturity

Each provider in the catalog is labeled Stable, Limited, Early, or Experimental. That reflects how complete OpenApp support is today, not how popular the vendor is in the market (for example, KNX is widely deployed but our integration is Early; PalGate is niche but Stable here).

Level	Meaning
Stable	Recommended when the provider fits. Core access flows are supported and actively maintained.
Limited	Production-viable with more setup or narrower scope; expect gaps vs mature native tools.
Early	Partial support only — not a default for production; consider Home Assistant or another bridge when available.
Experimental	Niche or non-production (including demo providers). APIs and UX may change.

The grid below is sorted Stable → Limited → Early → Experimental, then by sidebar order.

Integration support

Integration support is best-effort and depends on upstream capabilities and API stability. Read the provider page and maturity label before you commit.

When reporting an issue, include:

• Provider type (e.g. home_assistant, knx)
• Integration config fields (redact secrets)
• Device/entity external_id values involved
• Steps to reproduce + expected vs actual behavior

Available integrations

Sensitive config fields (API keys, tokens, passwords) are stored securely in AWS Secrets Manager.

Each integration includes:

• Product and manufacturer links
• Links to similar open-source integrations
• A practical getting-started guide
• A setup reference (required fields + explanations)

Shelly Cloud

Stable →

Control Shelly devices via Shelly Cloud.

Waveshare

Stable →

Connect OpenApp to Waveshare relay boards via MQTT + Modbus RTU.

Home Assistant

Stable →

Connect OpenApp to an existing Home Assistant instance.

PalGate Cloud

Stable →

Control PalGate gates and controllers via the PalGate cloud API.

Virtual Access

Stable →

A virtual provider type for portal-related workflows (directories, portals, apartments/units, and invite-driven capabilities).

MQTT

Limited →

Control devices by publishing MQTT messages to your broker.

go2rtc

Limited →

Watch IP cameras in the browser with low-latency WebRTC via go2rtc.

Shelly Websocket

Limited →

Connect to Shelly devices using a local websocket transport (currently limited).

KNX

Early →

Connect OpenApp to a KNX/IP gateway for local building automation control.

Virtual Budget

Experimental →

Track and update budgets as virtual entities inside OpenApp.

VI

Virtual Demo Devices

Experimental →

Temporary virtual opener and light devices for learning OpenApp without physical hardware.