Usage and quotas

Usage is measured in participant-minutes. A new account gets a one-time Sandbox grant; a paid plan gives a fixed allowance per 30-day period. Nothing is charged beyond that allowance, and a call that is already running is never cut off. This page explains exactly how the number is produced and what happens at each boundary.

Sandbox and paid periods#

What a participant-minute is#

A participant-minuteis one minute of one participant's time in a channel. Every participant is counted, including audience members who publish nothing. What matters is being connected, not being on camera.

Each participant's session is measured separately and rounded up to a whole minute. The rounding happens per session, not per channel and not per month.

A worked example

A 30-minute webinar. The presenter is there for the whole thing. Two guests speak for part of it. Forty people watch, some of them briefly.

A one-hour four-person team call is 240 participant-minutes. A two-person call for ten minutes is 20. Multiply the wall-clock length by the number of people connected, and you have a good estimate.

How usage rolls up#

A session opens when a participant joins and closes when they leave or when the channel ends. Closed sessions are folded into a daily total by a rollup job:

  participant joins ──► session opens
  participant leaves ─► session closes, duration recorded
                             │
                             ▼
                    rollup job (periodic)
                             │
                 ceil(durationSec / 60) minutes
                             │
                             ▼
              daily total, per project, per UTC day
                             │
                             ▼
        period usage = sum of daily totals since the period started

• Days are UTC days, and a session is credited to the UTC day it started.
• The window is your Sandbox's 30 days, or the current 30-day period of your paid plan. It is not the calendar month.
• Usage is summed across every project on your account, not per project. One cap covers them all.
• Only closed sessions are counted. A call in progress appears in your totals shortly after it ends, not while it runs.
• The rollup is idempotent — a session is counted once and only once.

Because rollup runs periodically, the figure in the console can lag a live call by a few minutes. It is not a real-time meter.

The 80% warning#

When your usage reaches 80% of the period's allowance, we send an email to the account owner with the percentage used, the minutes used and the cap. Infinite has no cap and no warning.

• It is sent once per period. Crossing 80% again later in the same period does not resend it.
• It goes to the account owner's email address, not to team members.
• There is no separate 90% or 100% email. Treat the 80% notice as your cue to act.

What happens at 100%#

Once usage reaches the period's allowance, new token requests are refused. The API returns 429 with a machine-readable code and the numbers behind the decision.

{
  "error": "Minutes for this period are used up.",
  "code": "QUOTA_EXCEEDED",
  "plan": "launch",
  "planLabel": "Launch",
  "capMinutes": 3000000,
  "usedMinutes": 3000412,
  "periodStart": "2026-09-01T08:14:02.000Z",
  "periodEnd": "2026-10-01T08:14:02.000Z",
  "upgrade": "https://applooma.dev/dashboard/billing"
}

Because tokens are issued by your server, this response arrives at your token endpoint. Handle it there and give your users a real message rather than a generic failure.

try {
  const { token, wsUrl } = await applooma.createToken({ /* … */ });
  res.json({ token, wsUrl });
} catch (err) {
  if (err.code === 'QUOTA_EXCEEDED') {
    // Your capacity ran out — not the user's fault. Tell them plainly,
    // and page whoever owns the account.
    return res.status(503).json({ error: 'Calling is temporarily unavailable' });
  }
  throw err;
}

No overage billing

We do not bill for minutes beyond your plan and we do not upgrade you automatically. Reaching the cap stops new tokens; it never produces an unexpected invoice. To keep going, move to a bigger plan from the billing page, or wait for the period to renew.

Plans and their included minutes are listed at applooma.dev/pricing.

Other reasons a token can be refused#

Check code rather than matching on the message text. Messages may be reworded; codes will not.

Seeing your usage#

Open the consoleand go to the billing page for your account. It shows the minutes used this period against your plan's allowance and when the period ends, so you can see how close you are before the 80% email arrives.

The session explorer lists individual sessions with their channel and timing, which is the fastest way to find out where an unexpected spike came from — usually a client that reconnects in a loop, or a test channel nobody left.

Keeping usage down#

• Leave the channel when the UI closes. A page that navigates away without leaving keeps a session open until the connection drops.
• Do not join before the user is ready. Joining a channel in a lobby screen meters everyone who is waiting.
• Use a separate project for development, so you can tell test minutes from real ones in the session explorer.
• Fix reconnect loops early. Each reconnect is a new session and each is rounded up to a whole minute.
• Remember that audience members cost the same as speakers. A large silent audience is where most minutes go.

Where to go next#