Sender Profiles: Multi-Tenant Resource Governance

Sender Profiles provide an architectural abstraction that enables true multi-tenancy within a single Sent organization. Rather than creating separate accounts for each business unit, brand, or customer, Sender Profiles allow you to isolate messaging identities while selectively sharing resources across organizational boundaries. This page explains why the model is built this way and what each governance choice trades off; the hands-on work lives in Creating a Sender Profile and Integrating Sender Profiles into Your Application.

The Sender Profile Abstraction

Traditional approaches to multi-tenant messaging force a binary choice: completely separate accounts with full isolation (and operational overhead), or a shared account with no isolation (and security risks). Sub-accounts in traditional CPaaS platforms mostly reproduce the first option, because every resource of the sub-account is isolated whether that serves you or not. Sender Profiles instead introduce a governed resource model that allows selective isolation and sharing on a per-resource basis: an agency can isolate each client's contact list while sharing one template library, something an all-or-nothing sub-account cannot express.

The Inheritance Architecture

Sender Profiles implement a hierarchical resource inheritance model with three levels:

• Organization level: the root entity that owns billing, compliance, and shared resources. Organizations serve as the administrative boundary and cost center.
• Sender Profile level: individual messaging identities that can inherit resources from the organization or maintain dedicated resources. Each profile has its own API credentials, sending identity, and configuration.
• Resource level: individual resources (billing, WhatsApp Business Account, contacts, templates, TCR registration) that can be inherited, shared, or dedicated per profile.

Resolution flows downward: when a profile inherits a resource, requests made as that profile transparently use the organization's copy; when the resource is dedicated, the profile's own copy is used and the organization's copy is invisible to it. Because the decision is made per resource rather than per account, the same profile can be fully isolated on one axis and fully shared on another.

Resource Governance Model

Each resource type implements a specific governance pattern:

Resource Configuration Patterns

Billing Inheritance

Billing governance offers three modes:

• Inherited: all charges flow to the organization's payment methods. Ideal for centralized cost management and single-invoice accounting.
• Dedicated: profile-specific billing with separate payment methods. Useful when clients or business units need direct billing.
• Mixed: the profile starts on the organization's billing but can be switched to its own billing later. Useful when a tenant may eventually take over payment.

Inherited billing is the better default for most organizations, because a single invoice and payment method keeps accounting simple; dedicated billing earns its overhead only when a client genuinely needs to be the payer of record.

Contacts and Templates

Contacts and templates implement a dual-mode sharing model:

• Inheritance: access resources from the organization level
• Sharing: allow this profile's resources to be accessed by other organization members

The two directions are independent, which is what makes the model expressive: a profile can consume the organization's shared template library without exposing its own contact list, or contribute templates upward while keeping its contacts private.

RCS Agent (Branded Sender)

RCS uses a branded sender identity (called an RCS Agent) instead of a phone number. Each Sender Profile can have its own dedicated RCS Agent with a custom logo, verified business name, and brand color displayed in the recipient's Google Messages inbox.

TCR Brand and Campaign

For US SMS compliance, TCR registration offers flexible inheritance:

• Fully Inherited: use the organization's brand and campaign
• Partially Inherited: inherit the organization's brand but register a dedicated campaign for the profile
• Dedicated: complete separate TCR registration for this profile

The reason partial inheritance exists is that TCR itself splits registration in two: a brand establishes the business identity behind the messages, while a campaign describes a specific use case being sent. Many multi-tenant setups share one legal entity but send a different use case per tenant, so inheriting the organization's brand while registering a dedicated campaign per profile mirrors how TCR divides responsibility. When tenants are distinct legal entities, dedicated registration is the only honest representation: TCR ties each campaign to the business responsible for the messages, which is why agencies and resellers register each client separately rather than bundling them under one campaign.

API Credentials and Isolation

Each Sender Profile has unique API credentials. The API key presented on a request determines which profile's resources the request uses: templates, contacts, numbers, WhatsApp Business Account, and TCR settings all resolve through the profile the key belongs to. This is the same governance model expressed at the API surface; no request parameter can reach across profile boundaries that the inheritance configuration has not opened.

Organization-level API keys are the one deliberate exception: they can act on behalf of a child profile by naming it explicitly (the x-profile-id request header), which platforms use to keep a single credential while still routing traffic per tenant. Both approaches, per-profile keys and organization-key scoping, are shown with code in Integrating Sender Profiles into Your Application; the scoping rules and error behavior are documented in Create and activate Sender Profiles via the API.

Architectural Patterns

Pattern 1: Agency Model

Centralized billing with dedicated WhatsApp Business Account per client:

• Billing: Inherited (agency pays)
• WhatsApp Business Account: Dedicated per profile (client branding)
• Contacts: Dedicated (client data isolation)
• Templates: Inherited + Shared (agency provides templates)

Pattern 2: Franchise Model

Shared resources with local brand presence:

• Billing: Inherited (franchisor manages)
• WhatsApp Business Account: Dedicated per location (local phone numbers)
• Contacts: Inherited (shared customer base)
• Templates: Inherited (franchise-wide messaging)

Pattern 3: Platform/ISV Model

Full tenant isolation:

• Billing: Dedicated (tenants pay directly)
• WhatsApp Business Account: Dedicated per tenant
• Contacts: Dedicated
• Templates: Dedicated

The three patterns are points on one spectrum, from maximum sharing to maximum isolation. Choose by asking who pays, who owns the audience, and who answers to regulators for each resource; the pattern falls out of those three answers rather than from the industry label.

Where to Go from Here

Now that you understand the governance model, you can act on it:

• Creating a Sender Profile walks through the dashboard wizard where each inheritance decision is made
• Integrating Sender Profiles into Your Application covers per-profile API keys, customer mapping, and webhook attribution
• Create and activate Sender Profiles via the API automates profile provisioning for tenant onboarding
• Multi-Tenant Architectures compares account-level alternatives to the profile model
• Roles and Permissions documents who can manage profiles within an organization