Access Portals

An access portal (or public portal) is a shareable entry point that lets visitors, residents, and guests interact with your building’s access system. Each portal has a unique public URL you can print as a QR code, add to signage, or share via links.

What portals do

Portals give you flexible ways to control who can use your building’s intercom or door:

Use case	Who uses it	What they see / can do
Building directory	Any visitor (no login)	List of residents to call or message
Resident quick open	Logged-in residents	One-tap button to open the door
Invitation	Recipients with an invitation link	One-tap open if they have a valid invitation

The same portal URL can behave differently depending on who visits it. For example, a lobby QR code may show a directory to strangers and a quick-open button to residents.

Key concepts

Name

Each portal has a short name (e.g. Lobby, Garage, Front). The name can be localized for multi-language buildings (e.g. { "en": "Lobby", "he": "לובי" }).

• The name is for humans (admins, support, building staff). It helps you recognize which portal you’re looking at when you have multiple portals.
• The name is not a secret and does not grant access. It’s safe to print on signage if you want.
• The name is not used for authentication and is not part of the public URL.

Why does OpenApp require a name? When a building has multiple entry points (lobby, garage, side gate), a short label makes it much easier to:

• Pick the right portal when creating invitations
• Understand portal lists at a glance
• Communicate with staff (“scan the GARAGE portal QR”)

Changing the name does not change the portal’s public URL. Deleting the portal invalidates its URL/QR code.

Public URL

Every portal gets a unique public URL: /p/{public_id}. This URL works without authentication. You can:

• Print it as a QR code for lobby signage
• Share it in messages or emails
• Embed it in apps or websites

Anyone with the URL can access the portal. What they see and can do depends on the portal mode (see below).

Device mapping (optional)

A portal can be linked or unlinked to a door/device:

• Linked: The portal is associated with a virtual_access_portal device. When opened, it triggers the door/gate opener.
• Unlinked: The portal only shows the building directory. There is no open action (directory-only mode).

Portal modes

The portal automatically shows the right experience based on who is visiting:

Building directory

Who: Visitors who are not logged in and do not have an invite.

What they see: A directory of residents and apartments. Each entry can offer call or message actions (depending on your settings).

Use case: Building entrance, lobby intercom. Visitors scan a QR code and choose who to contact.

Resident quick open

Who: Logged-in residents with permission to open doors in that building.

What they see: An “Open” button. One tap opens the door (if the portal is linked to a device).

Use case: Residents returning home. They log in once, scan the lobby QR, and get a direct open button instead of the directory.

Guest quick open

Who: Guests who have used a valid invite link (the invite is stored on their device).

What they see: An “Open” button, same as residents.

Use case: Delivery drivers, visitors with time-limited access. You send them an invite link; after they use it, they can open the door until the invite expires.

Creating and managing portals

1. Go to Access in the dashboard.
2. Select your organization and building (Virtual Access integration).
3. Click Add portal.
4. Enter a name (e.g. Lobby). You can add translations for other languages via the languages button.
5. Optionally link a door/device from the dropdown. If you leave it unlinked, the portal will only show the directory.
6. Save. You’ll see the Public URL in the table.

You can edit or delete portals at any time. Deleting a portal invalidates all existing QR codes and links.

Invite links

For guest quick-open, you create invite links that grant temporary access. Use the Invite page (linked from the Access dashboard) to generate invite URLs. Each invite can:

• Target a specific portal or apartment
• Have validity dates
• Grant open permission for that portal

Guests click the invite link; if valid, they can open the door from the portal page.

Auto-off implementation modes

When a door or light uses auto-off (turns off automatically after a delay), the implementation depends on the opener/light device’s integration. The door detail page shows the effective auto-off and the implementation method. Each mode describes how OpenApp and the device work together:

Mode	Description	Example
Unknown	Device is configured out-of-band (e.g. user configures via provider’s website or app). OpenApp cannot read or write the device’s auto-off settings. Also used when the device does auto-off via hardware (e.g. electric circuit with a timer).	Shelly device with timer set in Shelly app; electric strike with built-in timer
Device not configurable	Device does not support auto-off at all.	Simple relay with no timer capability
Device read-only	OpenApp can read the device’s auto-off configuration and validate it matches desired settings, but cannot write it. User configures out-of-band.	Future: Shelly Cloud v2 API with settings read support
Device configurable (online)	OpenApp configures the device immediately. When you change the delay in the dashboard, OpenApp writes the new setting to the device right away.	Waveshare relay board (Flash ON delay via Modbus)
Device configurable (reprovisioning)	Device requires a special programming/provisioning procedure. OpenApp cannot configure on demand; you must run provisioning when you change the delay.	Waveshare board before first MQTT provisioning
OpenApp controlled (per-command)	OpenApp sends a single request with the timer included (e.g. toggle_after). Fire-and-forget; no background task. Changing the delay takes effect on the next open.	Shelly Cloud (timer in each “on” request)
OpenApp controlled (task-based)	OpenApp sends “on”, then runs a background task to send “off” after the delay. Applies load on the system. Consider switching to device configurable when available.	Some integrations without per-command timer support

Policy: OpenApp vs device controlled

• OpenApp controlled: OpenApp decides when to turn off (per-command timer or task). The delay is stored in the portal config.
• Device controlled: The device has its own timer. OpenApp sends “on” without a timer; the device turns off after its configured delay. Configure the delay on the device (via provider app, provisioning, or API when supported).

Examples by integration

• Shelly Cloud: OpenApp controlled (per-command). Uses toggle_after or timer in each relay control request. No device config change needed; changing the delay in the dashboard takes effect on the next open.
• Waveshare: Device configurable (online) after provisioning. Uses Modbus Flash ON to set delay per command, or device’s stored timer when using device_controlled policy.
• Home Assistant: Depends on the underlying entity; often OpenApp controlled (task-based) when the entity does not support duration in the turn_on call.

Best practices

1. Use clear names — LOBBY, GARAGE, SIDE_ENTRANCE so you can tell portals apart.
2. Link devices when you need open — Unlinked portals are directory-only. Link a virtual_access_portal device to enable the Open button.
3. Test both views — Visit the portal URL while logged out (directory) and while logged in (resident quick-open) to verify behavior.
4. Print QR codes — Use the public URL to generate QR codes for lobby signage. Anyone who scans gets the same URL; the experience depends on whether they’re a resident or guest.

Related

• Virtual Access integration — How to set up the integration and devices for portals.
• Access — Manage portals in the dashboard.