The quiet-hours policy — the recipient-local send window you enforce on outbound sends per channel — used to be a dashboard-only control. It is now a settings document you can read and write through the workspace API, and the effective window per channel comes back resolved in the same response. Organizations that treat compliance configuration as code no longer need a manual click-through to audit or change their send windows.
This post announces the surface. The underlying semantics — recipient-local evaluation, deferral instead of dropping, opt-in per channel — are unchanged; the send-time optimization and quiet-hours explainer covers the recipient-local rule end to end if you want the background.
What shipped
Two endpoints under workspace settings expose the policy:
- `GET /api/v1/settings/compliance/quiet-hours` returns the policy document and the effective window per channel, resolved across the precedence chain — platform default → organization default → per-channel override. An absent channel reports the disabled platform default, so the response never has to be read defensively.
- `PATCH /api/v1/settings/compliance/quiet-hours` replaces the document with per-channel entries. Writes are owner-role only; the change takes effect on the next send.
The existing per-recipient preview endpoint keeps answering the one operational question the settings document cannot: GET /api/v1/compliance/quiet-hours/preview tells a caller whether a given send would go through right now, against which recipient-local timezone, and the next allowed start if it would not — the same intersection the send path enforces.
Why it matters
The quiet-hours gate was already deterministic at send time: the window is evaluated against the recipient's local time, a blocked send defers to the next allowed opening and reports next_allowed_at rather than failing, and a channel the tenant has not enabled falls back to the disabled platform defaults. What was missing was the management plane. An organization running its configuration in code — audit scripts, environment promotion, infra-as-config — had to treat quiet hours as the one compliance control that still required a human in a browser. The settings API closes that gap without changing the gate itself.
The tenant-owned posture carries over unchanged: the policy stays tenant-configured and opt-in per channel. Turning the management surface into an API does not add a platform-side mandate — the endpoints expose your policy to you; they do not set it for you.
What stayed tenant-owned
- Opt-in per channel. Enabling a window on a channel is your decision; the platform default for an absent channel is disabled, so you gate only the channels whose recipient-local windows you actually need.
- Deferral, not dropping. A blocked send holds and reports
next_allowed_at; the gate never silently discards traffic. - Campaign-level carve-outs. A campaign that carries its own window still wins over the fallback, and the settings document is the fallback — nothing in the new surface inverts that precedence.
- Reads need no owner. Reads return state; writes change it. Auditing the effective window is a read.
Three workflows the API opens
- Audit in code. Pull the document on a schedule and diff it against source control: anything that diverges is a drift to fix, and the response's resolved effective window per channel gives the audit the same number the send path would enforce.
- Promote environments deterministically. Write the same per-channel windows to staging and production workspaces from one definition instead of hand-porting a settings page.
- Preflight before dispatch. For sends whose timing is decided upstream, the preview endpoint answers "would this go through now, and if not, when?" with the same recipient-local intersection the gate enforces — no second implementation of the window math on your side.
The per-recipient behavior and the time-resolution chain behind it are documented in the quiet-hours configuration guide; the September 2026 release notes carry the original release note, the state-window overlap post covers how the federal window and the stricter state overlays intersect for US voice, and the announcements hub keeps this and the rest of the monthly record in one place.
Frequently asked questions
What is the quiet-hours settings API?
Two workspace-settings endpoints — GET and PATCH on /api/v1/settings/compliance/quiet-hours — that expose the cross-channel quiet-hours policy as a readable and writable document. The read resolves the effective window per channel across the precedence chain; the write replaces the document (owner role). The per-recipient preview endpoint is unchanged.
Where are the endpoints?
The settings pair lives at /api/v1/settings/compliance/quiet-hours; the write requires the owner role. The preview endpoint stays at /api/v1/compliance/quiet-hours/preview. The two surfaces compose — settings for configuration management, preview for per-recipient answers — and the full contract is in the quiet-hours configuration guide.
Did the way the gate evaluates change?
No. The window remains recipient-local, blocked sends still defer with next_allowed_at instead of dropping, and the gate remains tenant-configurable and opt-in per channel. What changed is only how the policy is managed — dashboard-only before, API-accessible now.
Is any of it mandatory?
No. An absent channel falls back to the disabled platform default. The endpoints expose your policy; they do not impose one, and no channel gains a blocked window until you enable it.
How does this relate to the TCPA federal window?
The federal 8 AM→9 PM dialing window for US voice is a separate, fixed rule that sits underneath anything a tenant configures — the settings API manages the tenant-owned per-channel gates, not the federal baseline. The state-calling-windows explainer walks that intersection.