Skip to content
OAOpenAppPhysical Security as a Service
Login

PalGate permissions and Linked Device

PalGate gates expose several independent permission concepts. OpenApp operators, PalGate gate administrators, and residents each interact with a different slice of this model. This guide is the reference for PalGate-side configuration; for linking OpenApp, see PalGate Cloud.

OpenApp links to PalGate through Linked devices → Link a device in the PalGate mobile app. PalGate calls this capability Linked Device (API field secondaryDevice on the user record).

  • Without Linked Device enabled for your phone on a gate, QR linking fails with errors such as Secondary device not authorized.
  • Linked Device is per gate and per phone. A gate administrator must enable it for each user who should link external apps.
  • Disabling Linked Device later revokes the OpenApp session for that gate without deleting the OpenApp integration row.
  1. Open the PalGate app and select the gate.
  2. Go to Settings (or gate administration).
  3. Open Users and select the phone number that will link OpenApp.
  4. Enable Linked Device / allow linking a secondary device.
  5. Save. The user can now scan the OpenApp setup QR code.
SymptomLikely causeAction
Secondary device not authorizedLinked Device disabled for this phone on this gateGate admin enables Linked Device (above)
Link succeeds but open failsUser lacks output1 / output2 on that outputGate admin grants relay permission for the correct port
Works on one gate, not anotherPermissions are per PalGate device idRepeat user setup on each gate device

Car multimedia / secondary token trade-off

Section titled “Car multimedia / secondary token trade-off”

PalGate token_type values (sms, primary, secondary) describe how the linked session was created — they are not admin indicators. Some users link via a car multimedia profile (secondary). That can work for opening but may carry different PalGate-side limits. Prefer linking with the same phone profile you use for day-to-day gate administration when you need the Users tab and directory management.

When OpenApp probes GET /v1/bt/device/{id}/user?pn=, PalGate returns:

FieldMeaning
adminGate administrator — can list and remove users on this device
secondaryDeviceLinked Device permitted (linked_device_permitted in OpenApp)
output1 / output2May trigger that relay
dialToOpenAuto-open on dial
outputNLatchRelay/latch mode permitted

Admin status is per device. The same phone can be admin on one gate and a regular user on another.

OpenApp roles: gate operator vs access administrator

Section titled “OpenApp roles: gate operator vs access administrator”

OpenApp separates operating gates from administering gate user directories:

OpenApp permissionPurpose
integrations:createCreate integrations, run PalGate setup wizard
integrations:readView integration, execute gate-open ops
integrations:users:listView Users tab / GET .../integration-users
integrations:users:writeInvite/resend/cancel and users_admin.remove_user

Suggested templates (document only — not auto-applied):

  • Gate operatorintegrations:create, integrations:read, plus device/entity permissions as needed; no integrations:users:*.
  • Access administrator — above plus integrations:users:list, integrations:users:write, and org users:create when inviting into OpenApp.

The org admin role includes all integration permissions.

Store in org metadata key palgate_policy (deploy default from config.toml when unset):

PolicyBehavior
warn_onlyAllow setup; show coordination warnings
warn_and_ackNon-admin must accept legal acknowledgment before completing setup (default)
admin_onlyBlock setup/create when linked account is not gate admin on the setup device

Linking a personal PalGate account into an OpenApp organization delegates physical access control to org operators. Actions through OpenApp must be coordinated with the PalGate gate owner and your organization’s policies. Non-administrator accounts can still open gates when PalGate permits, but cannot list the full user directory.

OpenApp records structured audit placeholders (integration create, credential link, acknowledgment, user removal) for future audit-log integration.