Connect by JBRH Open Connect

Allowance

An allowance is what remains of a period's permitted volume for one metered activity — emails sent today, messages ingested, calls made. It is reserved atomically on the server as work happens, so two things starting at once cannot both spend the last unit. Reaching one is a refusal with a reason, never a silent failure.

Status
Available What this means
Audience
both
In the app
#/billing
Last verified
Product version
6.3.2

Three kinds of limit, and one that never refuses#

KindShapeExample
Daily counterResets each day; reserved before the actionOutbound emails sent
Resource ceilingA cap on how many may exist at onceConnected mailboxes
Tracked onlyCounted for reporting; never used to refuseInbound WhatsApp messages
Not reachableDeclared on a plan, but nothing can consume it yetDimensions whose feature is off for that audience

The third row is a deliberate refusal to enforce. An inbound customer message costs nothing at the provider, and dropping one to protect a quota would lose a real customer's message in exchange for nothing — so it is counted and never blocked. The fourth is honesty about a limit that exists on paper: rather than deleting it, it is recorded as unreachable with the reason, and the moment the feature ships the register demands that it be enforced.

WhatsApp is metered in three separate allowances — service replies inside the 24-hour window, utility templates, and marketing templates — because those categories differ enormously in what they cost. One combined allowance would either starve the cheap replies to protect the expensive sends, or the reverse.

Why there is a register at all#

A limit is a promise in both directions: the workspace is held to it, and it is protected by it. A limit that is declared and never checked keeps neither promise, and that is exactly what had happened here — a plan listed nine limits, of which two were genuinely enforced, two were declared under key names nothing read, and the rest were numbers in a dictionary.

The failure was structural rather than careless: enforcement lived in two unrelated mechanisms with nothing tying either back to what was advertised, so a new limit could be added to a plan and silently never wired. The register now declares, for every dimension, how it is enforced, where, or honestly that its feature is not reachable — and a test walks it and fails when a reachable dimension has no enforcement site. That test is the part that stops the drift returning.

What an allowance is not#

An entitlement
The declaration of the limit. The allowance is the ledger counting against it, and only one of the two moves during a day.
An API rate limit
A per-client throttle on request frequency, which protects the service rather than the plan — see API rate limits.
A provider's own quota
Gmail, a messaging platform or a carrier each impose their own limits. Those are enforced by them, reported as their errors, and are not what the ledger counts.
A cost budget
Money, not volume. The voice budget stops a call the workspace cannot afford; an allowance stops the nth call of the day whatever it costs.

The distinction between the first and the last is the practical one. Running out of allowance is a plan question with a plan answer; hitting a cost budget is a spending decision, and the two produce different refusals for different reasons on the same screen.

Questions#

What happens to a message when the allowance is reached?

It is refused with the reason recorded rather than dropped. Held work stays held — an approval given while the allowance is spent is remembered, and the send happens when there is room. When the daily allowance is reached covers the email case in full.

Can a screen tell me how much is left?

Plan & Usage shows the counted usage against the declared limits. The number a browser holds is a display of the server's ledger and never the authority for whether an action may proceed.

Does the Owner workspace have allowances?

No. The operator has no plan, so nothing is counted against one — which is exactly why a capability must be checked as a customer as well before it is believed to work.