Invitation curfew
- Type
- invitation_curfew
- Category
- Invitations
- Enforced atWhen this policy is checked: while someone tries to open, while they create or change an invitation or hold, on a membership change or background sweep (lifecycle), or after a denial (record only).
- Access-time
- TiersWhere an admin can set this policy: the whole organization, one integration, or the physical device when the connector supports a device steward.
- OrgIntegrationDevice
- EnforcementEnforcement modes this type accepts. Enforce applies the row. Require approval (user sharing only) opens an admin approval inbox instead of blocking.
- Enforce
- DefaultWhat happens when no row of this type is configured.
- Not configured — no hour restrictions on invitation-based access.
An invitation curfew denies guest opens during a local time window even when the invitation schedule itself covers those hours. The invitation row is never rewritten. Admins and residents are never curfewed — the limit targets invitation-based access only. Local time uses the organization IANA timezone (for example Asia/Jerusalem); when unset, evaluation uses UTC. An organization admin may mark a specific invitation as exempt from curfew (`curfew_exempt`); the exemption is honoured on the public portal and invitation open paths only, not when the invited user opens through the entity-action API. When a curfew is written, the response lists existing invitations that overlap the window.
When it is enforced
Evaluated when someone opens a door or gate or triggers an entity action. If this policy applies, the open is denied even when roles and grants would otherwise allow it.
Where to set it
Settings → Policies (org), the integration Policies tab, or — on PalGate — the device steward Policies tab.
Policies never grant access. See thepolicies architecture guidefor how org, integration, and device tiers combine.
Arguments
The config object on create/update. Row fields outsideconfig are enforcement (this type acceptsenforce; any other value is rejected with 400), enabled (disabled rows never apply), and capability.
| Name | Type | Required | Values | Description |
|---|---|---|---|---|
| start | string | Yes | HH:MM | Inclusive start of the window as local `HH:MM` (00:00–23:59). May be later than end (midnight-wrapping, for example 22:30→06:00). |
| end | string | Yes | HH:MM | Inclusive end of the window as local `HH:MM`. At 06:00 the minute 06:00 is blocked and 06:01 is not. |
| output | string or integer | No | — | Device policies only. One output of the device, as the device reports it (PalGate `1` or `2`, a Shelly, Tasmota, or Waveshare channel index). When set, the policy binds only actions on that output; when omitted, every output of the device. An output that is not one of the device’s outputs, or `output` on an organization or integration policy, is rejected. If an action’s output cannot be identified, an output-scoped policy denies it. |
How overlapping rows combine
Any applicable enforcing row denies the open. Disabled rows never block. Device-tier rows bind every org on that hardware.
Example
A guest with a valid 48-hour invitation cannot open the door at 02:00. The guest sees a “subject to curfew” note. The invitation itself is unchanged and still works during allowed hours.
{ "start": "22:00", "end": "06:00"}Integrations
This type is documented on these connectors:
- Home Assistant (home_assistant)
- KNX (knx)
- MQTT (mqtt)
- PalGate Cloud (palgate_cloud)
- Shelly Cloud (shelly_cloud)
- Shelly Websocket (shelly_websocket)
- Tasmota (tasmota)
- Virtual Access (virtual_access)
- Virtual Demo Devices (virtual_demo)
- Waveshare (waveshare)
Related
- Policy catalog
- Policies architecture guide
- Notify on curfew attempt (notify_on_curfew_attempt)
- Quiet hours (quiet_hours)
- Max invitation duration (invitation_max_duration)