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 isolate messaging identities and their data, while letting billing and compliance stay with the organization. A profile is a customer of yours: it sends under its own identity or yours, and your customers never see Sent. This page explains why the model is built this way and what each 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 let the expensive resources (the legal identity, the registration, the payment method) stay with the organization, while each tenant's data stays isolated.

The Inheritance Architecture

Sender Profiles implement a resource model with three levels:

Organization level: the root entity that owns billing, compliance, and the identity a registration is filed against. Organizations serve as the administrative boundary and cost center.
Sender Profile level: individual messaging identities that can inherit compliance and billing from the organization. Each profile has its own API credentials, sending identity, and configuration.
Resource level: each capability is one of three things: dedicated to the profile, inherited from the organization, or absent.

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 copy is used and the organization's is invisible to it.

Contacts and templates are not inheritable, and never shared between profiles. A profile sees only its own contacts and templates, while the organization sees those of every profile beneath it. The four flags that used to govern this — inherit_contacts, inherit_templates, allow_contact_sharing, and allow_template_sharing — are now accepted and ignored on /v3/profiles, and every profile reads them back as false. See Migrating from /v3/profiles.

A sender is never inherited either. A brand and a campaign can be; a number cannot. A profile either has a dedicated sender or it has none and terminates through the shared routes for that country.

This model enables use cases like agencies managing multiple client brands, franchises with centralized billing but local operations, or platforms offering white-labeled messaging.

Resource Governance Model

Each resource type implements a specific governance pattern:

Resource	Pattern	Use Case
Billing	Organization, Dedicated, or Dedicated with organization fallback	Centralized cost control vs. separate invoicing
SMS sender	Dedicated per profile, or none	A dedicated number per tenant vs. terminating through shared routes
WhatsApp Business Account	Dedicated per profile, or none	Sharing an account would share its inbox and throughput, so it is not offered
RCS Agent	Dedicated per profile	Each Sender Profile can have its own branded RCS sender identity (logo, verified name)
Contacts	Always dedicated	A profile sees only its own contacts; the organization sees every profile's
Templates	Always dedicated	The same
TCR Brand/Campaign	Full/Partial/Dedicated	Unified compliance vs. separate brand registration

Resource Configuration Patterns

Billing Inheritance

Billing governance offers three modes, expressed on the API as one billing block:

Inherited ({"inherit": true}): all charges flow to the organization's payment methods. Ideal for centralized cost management and single-invoice accounting.
Dedicated (omit the block): profile-specific billing with separate payment methods. Useful when clients or business units need direct billing.
Dedicated with organization fallback ({"fallback": true}): the profile pays, and the organization's balance covers it when the profile's runs out. Useful when tenants pay directly but you guarantee their usage.

fallback cannot be combined with inherit, because inheriting already bills the organization. Inherited billing is the better default for most organizations, since 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 are always dedicated to the profile that created them. There is no inheritance and no sharing between profiles: a profile sees only its own records, and no request parameter can reach across that boundary.

Reads widen upward rather than downward. The organization sees every contact and template across its profiles, which is what makes centralized support and auditing possible without giving one tenant sight of another.

This replaces an earlier model where contacts and templates could be inherited from the organization and shared between profiles. The columns behind it are gone, so a tenant's customer data can no longer become visible to a sibling tenant by configuration.

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.

RCS Agent setup requires a one-time approval process with carriers and cannot be self-activated in the dashboard. Contact Sent to initiate RCS onboarding for your Sender Profile.

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

On the API, both halves live in the compliance object of the market they register: compliance.brand and compliance.campaign, each carrying inherit to say whose it is. See Managing channels.

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 key is returned once, by create, and never again. 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. No request parameter can reach across a profile boundary.

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)
TCR brand: Inherited, with a dedicated campaign per client
Contacts and templates: Dedicated per client; the agency still sees all of them from the organization

Pattern 2: Franchise Model

Shared resources with local brand presence:

Billing: Inherited (franchisor manages)
WhatsApp Business Account: Dedicated per location (local phone numbers)
TCR brand and campaign: Both inherited (one legal entity, one programme)
Contacts and templates: Dedicated per location, with the franchisor seeing all of them

Pattern 3: Platform/ISV Model

Full tenant isolation:

Billing: Dedicated (tenants pay directly)
WhatsApp Business Account: Dedicated per tenant
TCR brand and campaign: Both dedicated, since tenants are distinct legal entities
Contacts and templates: Dedicated, as always

The three patterns are points on one spectrum, and what varies between them is billing and compliance rather than data: customer data is isolated in all three. Choose by asking who pays, who the recipients believe they are hearing from, and who answers to regulators; 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
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
Managing channels covers giving a profile a sender and clearing its compliance
Multi-Tenant Architectures compares account-level alternatives to the profile model
Roles and Permissions documents who can manage profiles within an organization

On this page