7. Create demo access control

Virtual Access is the access-control layer. It does not open hardware by itself; it links portals, intercoms, residents, and invitations to underlying door entities (and optional lights for entry lighting that typically follow a door open).

Create a second integration:

1. Open Integrations and add Virtual Access.
2. Enable Demo mode for this guide.
3. Fill in the building location fields and save.

Demo mode is important: OpenApp marks the access-control resources as temporary too, and only allows them to link to temporary demo door (and optional light) entities from Virtual Demo Devices. This prevents accidentally building a real access-control setup on top of resources that will be deleted.

Under the Virtual Access integration, create the access resources used by the demo:

1. Create a portal device (virtual_access_portal) for the front door.
2. Link its opener to the Demo door entity.
3. Link its light to the Demo light entity so a portal Open turns the light on together with the door (defaults below); you can still drive Demo light on its own from the Virtual Demo Devices panel if you want to experiment.
4. Create an apartment/directory entity for the virtual intercom.
5. Create a door portal and connect it to the portal device.
6. Create an invitation for the portal or apartment.

A portal is the public entry point, usually opened from a QR code or link. The virtual intercom is the visitor-facing directory/call surface. An invitation is a temporary grant that lets a guest use selected access actions.

Add a few images while you are still in the dashboard:

• In Virtual Intercom, edit the apartment/resident entry and upload a photo. UI Faces has free AI-generated faces you can use for mock residents; for example, download this sample face, then upload it from the photo field.
• Edit the portal device for the front door and upload a door image. Pixabay door images are a good source for demos; for example, download this sample door, then upload it from the device image field.

If you automate the same setup with the SDK, use client.entities.upload_image or client.users.upload_image for photos (depending on whether the directory row is modeled as an entity or user), and client.devices.upload_image for portal door images—each accepts local bytes plus content type. When the file is already at an HTTP(S) URL, use upload_image_from_url on the same sub-clients to fetch and upload in one step.

For heavier automation and batch logic, you can also run OpenApp Scripting programs through the SDK. The door-opening examples in the HTTP API and SDK steps show both inline code and a .openapp file.

You now have Virtual Access in Demo mode wired so the portal’s primary path is Demo door, with Demo light as linked entry lighting, plus portal, intercom, and invitation objects the access product expects. So far this has been administrator setup in a signed-in browser; you have not yet confirmed that a resident or visitor sees the right surfaces and that Open still reaches the demo entities. The next step walks those human paths before you drop down to raw HTTP and code.

---

← Virtual opener and light · Test from the dashboard and portal →