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. Use it to:

• 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 door or gate. When opened, it triggers the opener. Production opens require a life-safety class and commissioning attestation on that door.
• Unlinked: The portal only shows the building directory. 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).

Public portal directory as a visitor who is not signed in.(click to enlarge)

Close

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

Visitor calls from the production mobile app are receive-only. Placing a directory call stays on this anonymous web portal (the physical door kiosk). Household members under 13 are not listed as callees; ages 13–15 ring only if a parent enabled visitor calls.

Resident quick open

Who: Signed-in residents with permission to open doors in that site.

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 sign 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.

Public portal guest view with a lobby door photo and Open after using an invitation link.(click to enlarge)

Close

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 site.
3. Open Add portal.

Access portals list for a site.(click to enlarge)

Close

4. Enter a name (e.g. Lobby). 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.

Portal detail with public URL and QR preview.(click to enlarge)

Close

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.

Invitation create wizard.(click to enlarge)

Close

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.

Owners can limit who may invite and which doors an invitation may grant (for example own-apartment doors only, or no master door) using access-control policies.

Hold open or closed

From the door page, Hold keeps every opener on that door open or closed until you clear it, until a date, or on a repeating schedule (every day, working days for the building’s region, weekend, or specific days). You can optionally keep lights on or off with the door.

Door page Hold controls.(click to enlarge)

Close

• Hold open / Stay on skips auto-close for that period. Hidden and rejected on means_of_egress and fire_door_assembly.
• Hold closed / Stay off ignores open commands. Guests still see the door on the invitation; Open is disabled and they see your reason, or “This door is held closed” if you left the reason blank. Hidden and rejected on means_of_egress and fire_door_assembly. PalGate hardware disable is only used on classified ingress_only or vehicle_gate openings.
• Setting a hold requires the set hold role (admins have it). Opening a door does not grant the ability to hold it.

If an opener is also used by another door, both doors show the same hold. Clearing it from one door does not drop a hold the other door still needs.

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.
• Tasmota: OpenApp controlled (per-command) and device PulseTime. OpenApp publishes POWER ON; Tasmota pulses the GPIO. Re-apply Backlog if you change pulse.
• 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.

Durable metal lobby signage

OpenApp does not ship a ready-to-mount plaque—you bring your own signage, which lets you choose material, size, copy, and branding. For weatherproof metal plaques, we suggest a third-party vendor such as PlaqueMaker — Signs & QR. You do not need to convert the public URL to a QR yourself: on this portal page, use Copy QR under the QR preview to copy the QR image to your clipboard, then paste it into the vendor’s plaque designer.

Related

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