Set default topic statuses per tenant that apply before a user makes their own choice.
and cover the concepts behind this page.
Preferences are usually the first reason people reach for tenants. A customer’s admin wants a category of notification switched off across their whole company, and that has to hold for users who never open a preference center.A tenant default sets a topic’s starting state for everyone in that organization. It overrides the workspace default for any send that names the tenant, and each user can still change their own from there.A tenant default is not a way to force a setting. A user who opts out stays opted out, because their own preference sits below the tenant’s in the . Mark a topic REQUIRED when it is transactional and nobody should be able to switch it off, which is the only status that ignores what the user chose.
A tenant default sets a topic’s status and nothing else. Channel routing is read from each user’s own preference record. A tenant’s has_custom_routing and custom_routing have no effect at send time, even though the API accepts and returns them, so a tenant that looks correctly configured can route nothing. To route a topic to specific channels, set it on the .
In the console, a tenant stores its defaults as a single default_preferences JSON object that you edit directly. Go to the tenant in the (Directory → Tenants) and open its Details tab. In the Default Preferences section, paste a JSON object whose items array holds one entry per topic. Each entry takes the topic_id as id and a status of OPTED_IN, OPTED_OUT, or REQUIRED. Save.
The Default Preferences JSON editor on a tenant's Details tab in the console.
This example opts one topic in, makes a second impossible to turn off, and opts out of a third. Topics you leave out keep their workspace default:
sets tenant defaults one topic at a time from your backend. Only the topics you include override the workspace default. Topics you leave out fall back to their workspace default state. The same default_preferences object shown above is what you send when you create or replace the tenant through the . Set one topic’s default with a body shaped like a topic, carrying its status.
import Courier from '@trycourier/courier';const client = new Courier({ apiKey: process.env['COURIER_API_KEY'],});await client.tenants.preferences.items.update('pt_01kx4h2jdafq8bk996nn92357r', { tenant_id: 'acme-corp', status: 'OPTED_IN',});
With Courier MCP, show me acme-corp's tenant settings and default preferences.
5
Verify the tenant default
Pick a user with no preference set for the Topic. Send them a message mapped to it in the Tenant’s context, including tenant_id. Confirm delivery follows the Tenant default, not the workspace default.
Reading a user’s preferences does not show you the tenant default. The call returns the topic-level default_status even when , so a tenant default you set correctly looks absent from the user’s side. Read the tenant itself for its defaults, and use a test send to confirm what a user receives.
Topics you leave out keep the workspace default.default_preferences is a partial override rather than a full replacement, so removing a topic from it restores the workspace state rather than clearing the topic.
A tenant default only applies to sends that name the tenant. The same user, sent to without a tenant_id, falls back to the workspace default unless auto-infer resolves the tenant for you.
⌘I
Assistant
Responses are generated using AI and may contain mistakes.