Skip to main content

Capacity

A provisioned line handles one active call at a time. Multiple teams can share that line sequentially. For simultaneous demos, each call needs its own provisioned, ready line and an isolated agent session. These are capacity examples, not a promise of how many lines are assigned to your project. Confirm your reserved line count, FaceTime handles, and demo window with Chert. Available concurrency can be lower when a line is busy, offline, or not ready, or when your LiveKit or model-provider limits are reached.

Plan a multi-team event

  1. Decide how many teams must demo simultaneously.
  2. Arrange that many independently provisioned lines with Chert, or schedule sequential slots on fewer lines.
  3. Assign each team a handle and time slot. One handle still has one active call slot; the opt-in outbound queue below waits for that slot rather than increasing concurrency.
  4. Use a separate LiveKit room and agent session per active call. Sharing a project does not require sharing a room.
  5. Rehearse all planned simultaneous calls and confirm that each line becomes ready again after hangup.
BYOR credentials and the remote_participant_identity can be chosen per accepted call, so the same line can serve different team agents at different times. Your webhook owns that selection; use your demo schedule or application context rather than relying on a caller hash as authenticated team identity.

Operational limits

  • Inbound decisions: respond within the configured decision deadline, five seconds by default. Missing or invalid decisions fail closed.
  • Bridge tokens: include valid integer nbf and exp claims with exp - nbf no greater than 7,200 seconds.
  • Audio participants: provide exactly one eligible remote participant with one unmuted published audio track. Silent auxiliary participants may be present.
  • Outbound idempotency: use an Idempotency-Key of 8–200 characters. Reuse it when retrying the same creation request.
  • Readiness: an available line can still have an offline or unready worker. Inspect current worker readiness before testing.
  • Video: agent video and caller capture have independent requirements. Subscribe to caller video only when capture is enabled and available; handle mute or track removal. Audio-only calls do not include video.
See BYOR for credentials and media requirements.

Waitlists, queues, and group capacity

A shared-slot allocation waitlist is separate from a queue for a busy call. GET /api/v1/shared-waitlist reports the project’s current allocation position; a place in the waitlist is not an assigned line. For outbound calls on a busy shared line, when_busy: "queue" opts into waiting for up to two minutes. The default is "fail". HTTP 202 with queued: true means waiting, not call allocation. Read GET /api/v1/calls/queue/{queue_id}; when its state becomes ready, repeat the original create request with the same idempotency key and valid call-scoped credentials. The turn lasts 20 seconds. DELETE /api/v1/calls/queue/{queue_id} cancels waiting. Handle expired, cancelled, and failed states without assuming a call was placed. An enabled group call uses one line slot for the entire conversation. Experimental busy incoming-attempt reporting does not create another slot or automatically answer the second caller.