Skip to main content
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 .

Prerequisites

Set tenant defaults

1

Set defaults in the console

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.
A tenant's Details tab with the Default Preferences JSON editor holding three topic entries and reporting Valid JSON

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:
2

Set a default with the API

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.
3

Remove a tenant default

removes a tenant default for a topic, reverting it to the workspace default:
4

Read the defaults back

Read the tenant back to confirm its defaults. The default_preferences field on the returned tenant holds the topics you set. Call the :
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.

Limits & behavior

  • 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.