Policy catalog
Policies are administrative limits that layer on top of roles. A policy never grants access; it only narrows what someone could already do. The one exception is emergency free egress, which stops OpenApp from denying opens. For the three-tier model (org / integration / device) and how rows combine, see the policies architecture guide.
Use the catalog below to find a policy by name, category, when it is enforced, or tier. Categories start collapsed — expand one to see its policies. Machine policy_type keys are on each type page. Each card opens a page with every argument, allowed values, and an example config.
Row fields
Section titled “Row fields”Every policy row has these fields next to config:
| Field | Values | Meaning |
|---|---|---|
policy_type | a type from the catalog | Unknown types are rejected with 400. |
enforcement | enforce, or require_approval on user_sharing only | Omitted means enforce. Any other value, including audit_only, is rejected with 400. |
enabled | boolean | Disabled rows are ignored. |
capability | invitations, users_admin, switchable, or unset | Optional scope. Unset applies everywhere. Emergency types reject it. |
config | object | Type-specific; see each page. |
A type written at a tier its page does not list (for example an emergency type on an integration) is rejected with 400.
Common config fields
Section titled “Common config fields”A type accepts only the fields its evaluator applies. Any other field in config, or a capability the type does not support, is rejected with 400, so a saved policy never claims a restriction that nothing enforces. Each type page lists its fields. Two selectors appear on many types:
| Field | Values | Meaning |
|---|---|---|
applies_to | non-empty array of the principal kinds the type lists | Principal kinds the row binds. A caller is every kind it is at once (for example a member who is also a resident), and the row binds when any of them is listed. A bare string, kinds the type does not list, and [] are rejected. Omitted means the type’s default. |
output | string or integer | Device policies only. One output of the device (PalGate 1 or 2; a Shelly, Tasmota, or Waveshare channel index). The value must be one of the device’s outputs. Omitted means every output of the device. If an action’s output cannot be identified, an output-scoped policy denies the action. |
Author org policies on Settings → Policies, integration policies on the integration Policies tab, and device-tier policies (PalGate steward) on the device Policies tab.
Catalog
Section titled “Catalog”47 policies
Invitations
Guest invites — duration, uses, who may create them, and which doors they can cover.
23 policies
Invitations
Guest invites — duration, uses, who may create them, and which doors they can cover.
23 policies
Invitation curfew
Blocks invitation-based opens during a forbidden time window (for example nights). Admins and residents are never curfewed; existing invitations are evaluated live, not modified.
Max invitation duration
Caps how long each invitation schedule slot may last. Longer create or update requests are rejected, not shortened.
Max share duration
Caps how long a short-term share (TTL invitation) may last. Combined with max invitation duration as the stricter of the two. Longer create requests are rejected, not shortened.
Default share uses
When the author omits a use count on a share, store this default. The system default is 1 when this policy is not configured.
Max share uses
Ceiling on how many times a share may be used. Unlimited shares require allow_unlimited on every applicable row and no invitation_max_uses.
Max invitation uses
Requires a finite use count and rejects unlimited invitations or counts above the cap.
Max invitation devices
Caps the number of unique guest browsers or app installations that may register an invitation.
Max active invitations per user
Caps how many enabled, unexpired invitations one person may have at once.
Require invitation expiry
Forbids open-ended recurring invitations that never end.
Allowed entry kinds
Limits which portal types (door, gate, boom-gate) an invitation may grant. Combination intersects allowed sets.
Require invitation justification
Requires a non-empty creation justification when creating or updating an invitation.
Max doors per invitation
Caps how many unique portals a single invitation may grant.
Own-listing doors only
Invitations may only grant doors the author can open as a member of an allowed listing. Org/integration admins are exempt unless applies_to says otherwise. PalGate-only sites with no listings fail for members.
Prohibit master-door invitations
Rejects an invitation if any granted portal’s door is a listed OpenApp device id (union of ids; never client-forged hardware ids).
Who may invite
Literal allow-list of roles that may create invitations. Combination intersects lists; empty intersection means nobody. Not admin-exempt. Compose with user_sharing (both must pass).
No invitation re-share
Listing residents cannot create or update invitations. Org and integration rows bind residents by default, not generic members or admins. Device-tier rows bind everyone.
Require invitation identity
Requires a host PIN, a host-attached photo, and/or a verified invitee phone before an invitation can be created or used.
Invitation allowed days
Limits invitation-based opens to listed weekdays, minus blackout dates and optional holiday-calendar dates. Existing invitations are evaluated live, not modified.
Holiday calendar
Lists organization-local ISO dates that invitation allowed-days can treat as holidays. This type does not deny access by itself.
Require named invitations
Forbids invitations that anyone with the link may use, so every invitation must name who it is for.
Allowed invitation contact kinds
Restricts which kinds of contact an invitation may name: organization people, groups, email, or phone.
Max contacts per invitation
Caps how many contacts one invitation may name.
Max notifications per contact per day
Caps how many times one invitation contact may be notified in a UTC day.
Holds
Door hold-open and hold-closed — who may set a hold and for how long.
5 policies
Holds
Door hold-open and hold-closed — who may set a hold and for how long.
5 policies
Require hold expiry
Members and residents cannot set a permanent hold. Temporary (and unless also forbidden, weekly) holds are still allowed.
Max hold duration
Caps how long a temporary hold can last. Longer requests are rejected, not shortened. PalGate hardware latch max is an extra cap when present.
No repeating holds
Members and residents may only set a one-shot hold, not a repeating calendar schedule.
Allowed hold modes
Limits members and residents to hold-open, hold-closed, or both (for example, stay-off for lights but not stay-on).
No holds
Members and residents cannot set a hold, even if an admin granted the set-hold role. Device-tier without applies_to binds everyone, including admins.
Sharing
Who may share access or manage linked users outside invitations.
6 policies
Sharing
Who may share access or manage linked users outside invitations.
6 policies
User sharing control
Restricts whether non-admins may share access or create invitations out of band — block outright or require admin approval.
Linked-account admin
Controls whether a non-admin PalGate vendor account can complete setup: warn only, warn and require acknowledgment, or block until an admin account is used.
No transitive delegation
Invite create: org admin or listing admin only. Vendor users_admin writes (except list): org admin only. Runs in addition to user_sharing.
Approval threshold
Requires N distinct organization-admin approve votes before a pending policy approval proceeds. Any deny denies. Self-approval does not count.
External group sharing
Controls whether rosters owned outside this organization may be used here, and how much delegation that grants.
Agent group write
Lets this organization’s agents manage groups: create, edit and delete them, change members, and decide links and admissions.
Lifecycle
Move-out and idle membership — revoke leftover invites without deleting the user.
2 policies
Lifecycle
Move-out and idle membership — revoke leftover invites without deleting the user.
2 policies
Revoke invites on move-out
When a resident is removed from a listing, enabled invitations they authored that grant that listing’s doors are revoked.
Expire dormant users
After idle days, a background sweep revokes that person’s invitations and removes residencies. The user account is not deleted. Admins are exempt unless included.
Agent safety
Time windows, throttles, and extra confirmation for agents, API keys, and guests.
4 policies
Agent safety
Time windows, throttles, and extra confirmation for agents, API keys, and guests.
4 policies
Quiet hours
Blocks access during a local hour window for listed principal kinds (agents, API keys, invitations). Admins are not restricted unless included.
Rate limit
Throttles entity opens per principal in a sliding window so retrying agents cannot exhaust door quota.
Require step-up
Requires extra confirmation before a physical write for the listed principal kinds.
Anti-tailgating cooldown
After a successful open of an entity, further opens of that entity are denied until the cooldown elapses. Admins are exempt by default.
Operational
Site-wide lockdown and notifications when a policy denies access.
7 policies
Operational
Site-wide lockdown and notifications when a policy denies access.
7 policies
Emergency lockdown
When active, denies non-admin inbound cloud opens. Does not lock a means of egress or fire-door assembly, and is not a building lock-in.
Emergency free egress
When active, OpenApp will not deny inbound cloud opens. This is not fire-alarm release.
Notify on curfew attempt
Emits an audit event (and configured channels) when curfew blocks an open.
Maintenance window
During a local hour window, only listed roles may open. Empty role intersection means nobody. Technicians match the same way as who-may-invite.
Notify on first use
Emits an audit event when an invitation’s use count goes from 0 to 1, if audit is among the channels.
Notify on new sharing
Emits an audit event after users_admin writes (except list) and after invitation create that actually shares, if audit is among the channels.
Notify on group membership change
Records an audit event when the roster behind a group changes.
No policies match those filters.