Quotas & plan limits
Every organization runs on a plan (tier) that grants a set of quotas. A quota is a limit on how much of a given resource or action your organization can use. The Billing page in the dashboard shows your current usage against each limit, lets admins switch plans, and warns you as you approach a cap.
How quotas work
Section titled “How quotas work”Quotas fall into two shapes:
- Capacity quotas (unit:
count, period: lifetime) cap how many of a resource can exist at once — devices, entities, zones, integrations, API keys, and org members. These are checked before creation. When you are at the cap, the create request fails with429 quota_exceeded; delete something or upgrade to make room. - Metered quotas (period: per day, per month, or per session) count actions over a rolling window — door opens, AI requests, video sessions, and so on. When the window’s limit is reached, further actions are rejected until the window rolls over (or you upgrade).
Each quota carries a machine-readable unit so clients can format it correctly:
count— a plain tally (door opens, devices, …).seconds— a duration (video session length), shown as minutes/hours in the UI.
Quota reference
Section titled “Quota reference”| Quota key | Consumed by | Unit | Period |
|---|---|---|---|
entities | Creating an entity | count | lifetime (capacity) |
devices | Creating a device | count | lifetime (capacity) |
zones | Creating a zone | count | lifetime (capacity) |
integrations | Creating an integration (and inbound transfers) | count | lifetime (capacity) |
api_keys | Minting an API key (incl. voice keys) | count | lifetime (capacity) |
org_users | Adding a user to the org / accepting an invite | count | lifetime (capacity) |
door_opens | Opening a door (switchable.open, portals, sessions, invites) | count | per day and per month |
voice_invocations | Opening a door via a voice/API key | count | per day |
portal_views | Fetching a public portal’s config | count | per day |
scripting_executions | Running a scripting program | count | per day |
geocoding_requests | Creating/updating a location that is geocoded | count | per day and per month |
ai_requests | AI translation and apartment enrichment | count | per day and per month |
video_sessions | Starting a video session | count | per month |
video_session_duration_seconds | Video call airtime | seconds | per session |
Approaching and exceeding limits
Section titled “Approaching and exceeding limits”- Warnings. A banner appears in the dashboard once any quota crosses a high-usage threshold, and the Billing page color-codes each meter. The banner is dismissable per organization and reappears if usage gets worse.
- At the cap. Capacity creates return
429 quota_exceeded; metered actions are rejected until the window resets. - Changing plans. Admins (members with
billing:manage) can switch tiers from the Billing page. A downgrade is allowed even when current usage exceeds the new tier’s caps — existing resources keep working, but new creates are blocked until you are back under the cap, and the Billing page marks which quotas are over the lower tier.
Over-capacity remediation
Section titled “Over-capacity remediation”If an organization downgrades (or otherwise ends up over its plan limits), OpenApp does not delete your data abruptly. Instead it applies a gradual, reversible lifecycle:
- Warned — the org is flagged as over capacity; admins are nudged to act.
- Degraded — excess resources introduce friction. Opening a flagged (excess) door is intentionally slowed (never blocked); a readable notice explains why and points the user to their admin. Non-admin members are also blocked from creating new resources or invites while the org is over capacity. Admins stay exempt so they can remediate.
- Marked for deletion — after further grace time, excess resources are marked, and the friction escalates to more users.
- Soft delete — only after all grace periods elapse are excess resources soft-deleted (recoverable for a retention window). Org members are never removed, and no one is locked out of their doors.
The friction level is a continuous value (0–1) that scales the door-open delay, so the experience worsens gradually rather than flipping a switch. Admins can choose which excess resources are wound down first via a selection policy (newest-first, oldest-first, least-recently-used, or manual) and can pin specific resources to keep. All of this is visible on the Billing page’s remediation panel.
To resolve degradation, upgrade the plan or free up capacity (delete or pin resources) until usage is back within the tier’s limits; the lifecycle then heals automatically.