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.
Linked Device (secondary device linking)
Section titled “Linked Device (secondary device linking)”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).
Why it matters
Section titled “Why it matters”- 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.
Enable Linked Device (gate administrator)
Section titled “Enable Linked Device (gate administrator)”- Open the PalGate app and select the gate.
- Go to Settings (or gate administration).
- Open Users and select the phone number that will link OpenApp.
- Enable Linked Device / allow linking a secondary device.
- Save. The user can now scan the OpenApp setup QR code.
Troubleshooting link failures
Section titled “Troubleshooting link failures”| Symptom | Likely cause | Action |
|---|---|---|
Secondary device not authorized | Linked Device disabled for this phone on this gate | Gate admin enables Linked Device (above) |
| Link succeeds but open fails | User lacks output1 / output2 on that output | Gate admin grants relay permission for the correct port |
| Works on one gate, not another | Permissions are per PalGate device id | Repeat 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.
Gate user fields (API)
Section titled “Gate user fields (API)”When OpenApp probes GET /v1/bt/device/{id}/user?pn=, PalGate returns:
| Field | Meaning |
|---|---|
admin | Gate administrator — can list and remove users on this device |
secondaryDevice | Linked Device permitted (linked_device_permitted in OpenApp) |
output1 / output2 | May trigger that relay |
dialToOpen | Auto-open on dial |
outputNLatch | Relay/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 permission | Purpose |
|---|---|
integrations:create | Create integrations, run PalGate setup wizard |
integrations:read | View integration, execute gate-open ops |
integrations:users:list | View Users tab / GET .../integration-users |
integrations:users:write | Invite/resend/cancel and users_admin.remove_user |
Suggested templates (document only — not auto-applied):
- Gate operator —
integrations:create,integrations:read, plus device/entity permissions as needed; nointegrations:users:*. - Access administrator — above plus
integrations:users:list,integrations:users:write, and orgusers:createwhen inviting into OpenApp.
The org admin role includes all integration permissions.
Organization PalGate policy
Section titled “Organization PalGate policy”Org-tier policy type linked_account_admin (default warn_and_ack when no row exists), authored in Settings → Policies:
| Policy | Behavior |
|---|---|
warn_only | Allow setup; show coordination warnings |
warn_and_ack | Non-admin must accept legal acknowledgment before completing setup (default) |
admin_only | Block setup/create when linked account is not gate admin on the setup device |
Who may share gate users through OpenApp is a separate user sharing policy. See Policies and the policy catalog.
Gate administrator as the OpenApp device steward
Section titled “Gate administrator as the OpenApp device steward”The PalGate gate administrator role (the admin field above) is what unlocks OpenApp’s strongest policy tier: device-level policies. A verified gate admin can become the device steward and impose limits — such as a curfew or sharing controls — that bind every organization and integration pointing at the same physical gate, not just their own.
- Eligibility uses the same per-device admin check described here: only a linked account that is a verified gate administrator can become steward. A non-admin (the Secondary device not authorized / “redacted” state) can never set device policies.
- There is one steward per physical gate, even though PalGate allows several gate administrators — the first verified admin to set a device policy claims it.
- The gate identity is auto-detected from PalGate (the gate id) and is read-only; ownership is verified against the real gate, so it cannot be spoofed.
This is the mechanism behind Regaining control of shared devices, which walks through the shared-gate scenario end to end.
Coordination and legal notice
Section titled “Coordination and legal notice”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 PalGate linking actions in the org audit log (integration create, credential link, non-admin acknowledgment, user removal). Review them on the dashboard Activity page or via the audit API.