Skip to content
OpenAppPhysical access, simplified
Login

Max active invitations per user

Type
invitation_max_active_per_user
Category
Invitations
Enforced at
Authoring-time
Tiers
OrgIntegrationDevice
Enforcement
Enforce
Default
Not configured — no cap on how many invitations one person may keep active.

The author cannot have more than max enabled, unrevoked invitations that are still in force. Create is rejected once the cap is reached.

When it is enforced

Evaluated when someone creates or updates an invitation, hold, or share. Requests that would exceed the limit are rejected — they are not silently rewritten.

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. Shared row fieldsenforcement (enforce, require_approval,audit_only) and enabled apply to every type;audit_only and disabled rows never block.

NameTypeRequiredValuesDescription
maxintegerYesMaximum concurrent active invitations per author. Must be greater than 0.
outputstring or integerNoOptional channel or output id. When set, the policy binds only that output. When omitted, it binds every output of the tier target. A scoped row does not apply when the acting output is unknown.

How overlapping rows combine

Minimum of max across applicable rows. Reject, do not clamp.

Example

A resident with five active invitations cannot create a sixth until one expires or is revoked.

config
{
"max": 5
}

Integrations

This type is documented on these connectors:

The OpenAPI contract names this object InvitationCountLimitPolicyConfig:

{
"max": 5,
"output": "main"
}

max must be positive. Multiple applicable rows combine by taking the smallest limit.