Campaign limits: audience-cap override and default quiet-hours window
Two campaign-safety controls live on one page: Settings → Campaigns (titled “Campaign limits” in the dashboard header). One card raises the per-campaign audience cap, the other sets the org-wide default quiet-hours window that drip and journey sends fall back to. Both are enforced server-side on every campaign send; the page only exposes them. You need the owner or admin role to change either control — the dashboard hides the page for other roles, and the API returns403 for
them. Any authenticated caller can read both settings to check the posture
that applies to their own sends.
The two cards
Each card writes only its own keys on the organization settings document,
so saving one never overwrites the other — or the sibling campaign
settings (approval policy, rate overrides).
Per-campaign audience cap
Every campaign you send admits at most a platform-default audience (100,000 recipients) unless you lift it. The default exists so an accidentally-over-broad segment or a mis-keyed list size cannot dispatch to every contact you hold before anyone reviews it. Enable Large-audience override and set a Maximum audience size anywhere inside the platform band — from the 100,000 floor up to 10,000,000 — when your verified contact lists genuinely need a larger blast. The cap is resolved on every send at dispatch time, so raising it applies to campaigns you launch after the save; it never truncates an in-flight campaign’s already-admitted recipients. Drip and journey senders should lift the cap only as far as the segment they actually target. The sequence each drip enrolls still resolves against this same cap, so a journey whose trigger segment is above the cap never admits its overflow — it holds the excess enrollments until you raise the cap high enough. Lift the cap back down (or disable the override entirely) once the large-list campaign is done. Recall that each send consumes per-contact frequency caps and your channel’s throughput ceiling regardless: the audience cap decides who enters, not how fast they are messaged.Default quiet-hours window
The quiet-hours gate holds sends inside a recipient-local window. The fallback that page sets here applies only to drip and journey sends whose campaign row carries no explicit window of its own — one-shot campaigns and API sends resolve their own per-campaign window first. Resolution order for a drip or journey send: the campaign’s own window, then this org fallback, then the platform default 21:00 → 09:00 recipient-local. Any tenant can narrow the fallback to their own jurisdiction’s calling window (e.g. EU 22:00 → 07:00). Narrowing never relaxes the always-on TCPA federal dialing-window guard for US campaign and dialer voice — that guard is platform-owned and this page can’t touch it. For the full configuration picture across every surface that reads your quiet-hours posture, see Quiet hours configuration. The conceptual map of every gate a send walks (wallet, quiet hours, frequency caps, content-suppression) lives in Send gating & quiet hours.Interaction with campaign-duration and rate overrides
The audience cap and this fallback window are the campaign-safety knobs on Settings → Campaigns; other campaign settings pages cover duration, approval policy, and rate. Rate-related limits however resolve independently:- Channel rate overrides raise the per-minute throughput ceiling on individual dedicated send channels — the rate at which admitted recipients leave, not who enters.
- The audience cap decides admission; the quiet-hours fallback decides timing; rate overrides decide pace. Tune them separately and check all three before a rollout.
API surface
Both cards are backed by public endpoints; any authenticated caller can read them, owner/admin writes them. Read the audience cap:PUT with audience_override_enabled: true but no
max_audience_size, or with a quiet-hours enabled: true missing either
hour, returns 422. Overnight windows (e.g. start 22, end 7) are
accepted.
Edge cases
- Journey sends crossing the window. A drip or journey enrolled
mid-window keeps walking each contact when their recipient-local window
reopens; enrollments land per-recipient rather than pausing the whole
journey. The blocked enrollment reports
next_allowed_at— re-queue at that timestamp instead of retrying the whole batch in a loop. - Re-warming a lifted cap. After you raise the ceiling past your historical max and lift it back down later, in-flight journeys still resolve against the cap at each step’s dispatch — re-queue held enrollments against the current cap to make sure they don’t stall silently.
- Cap rollback safety. Lowering the cap past a live campaign’s planned audience doesn’t abort in-flight recipients already admitted; it only gates the next dispatch.