Templates

A template in Sent is a reusable, channel-agnostic message definition. It describes what a message says (its text, variables, media, and buttons) once, and the platform adapts that definition to the formatting rules, limits, and approval processes of each channel it is delivered on.

Rather than forcing developers to manage channel-specific message formats, templates provide a unified abstraction that automatically adapts to the capabilities and requirements of each messaging platform.

The Template Abstraction

Before template systems, messaging applications faced significant architectural challenges. Developers had to manage the complexity of different messaging channels, each with their own formatting rules, character limits, and approval processes.

Templates abstract away the complexity of different messaging channels, providing a unified interface for content creation and management.

Channel-Agnostic Messaging

Templates introduce a channel-agnostic message definition layer that describes communication intent and structure without being bound to specific channel implementations:

• Unified Definition Model: A single template definition automatically generates appropriate content for all supported channels, eliminating the need for channel-specific message creation.

• Rich Content That Degrades Cleanly: Templates support rich content (media, interactive buttons, structured layouts) that gracefully degrades to simpler formats on channels with limited capabilities.

• Regulatory Compliance: Templates manage complex approval workflows required by different channels, including WhatsApp (via Meta) and RCS (via your RCS Sender Profile; see Sender Profiles), without developer intervention.

• Per-Channel Overrides: Templates support an rcs channel override in the body, letting you define separate rich content (rich card layout, carousel, suggestion chips) for RCS while the same template falls back to plain text on SMS. This means a single template ID covers all channels without duplicate templates.

Template Anatomy

Templates use a declarative content model with four primary components, each supporting dynamic content:

• Body (required): The core message content that every channel must support, including text with embedded variables, links, and media references. On SMS, body length determines how many billable segments the rendered message becomes. See SMS Encoding & Message Length.

• Header (optional): An introduction that can include text or media, adapting to each channel's capabilities. Headers render natively on WhatsApp and are prepended to the message text on RCS; SMS delivers body content only, so headers are omitted there.

• Footer (optional): Additional context such as disclaimers or contact information, appended or integrated based on channel formatting capabilities.

• Buttons (optional): Interactive elements including quick replies, URL buttons, and custom actions that channels implement according to their interaction models.

Dynamic Content

Templates implement an entity system that handles dynamic content insertion with two primary types:

• Dynamic variables

  • Text variables: Dynamic placeholders with type information (text, number, date, etc.) and sample values for testing. The system ensures type safety and provides meaningful fallbacks when values are missing.
  • Media variables: Image and file references with automatic optimization, CDN delivery, and format adaptation that ensures rich content is delivered appropriately across channels.

• Dynamic links

  • URL references with built-in optimization including automatic shortening, click tracking, and channel-appropriate formatting that adapts to channel constraints.

Content Adaptation Mechanics

The template system processes content through sophisticated adaptation:

Structural Transformation: Templates define ideal message structure that automatically transforms to match each channel's capabilities: full structure for WhatsApp, body-only text for SMS.

Variable Substitution: Type-aware rendering ensures variables display appropriately for each channel while maintaining business meaning and context.

Interactive Element Conversion: Buttons render as interactive buttons on WhatsApp and as suggestion chips on RCS (the first four). SMS delivers body content only, so buttons are not delivered there. Essential links belong in the body.

A Worked Example

Consider a shipping notification defined once, with two text variables and a dynamic link in the body, plus a URL button labeled "Track your order":

Hi {{0:variable}}, your order {{1:variable}} has shipped. Track it here: {{2:link}}

In the template definition, placeholder 0 is declared as a text variable named customerName and placeholder 1 as one named orderNumber, each with a sample value used for previews and channel approval; placeholder 2 is a link entity carrying the tracking URL. When your app sends the template with parameters: { "customerName": "Maria", "orderNumber": "#4321" }, the one definition renders differently per channel:

• On WhatsApp: "Hi Maria, your order #4321 has shipped. Track it here: …" arrives as a structured template message with the link in the body and a tappable Track your order button beneath it.
• On SMS: the same body arrives as a plain text message. The link in the body still reaches the recipient, but the button is not delivered, because SMS carries body content only.

The business meaning is identical on both channels; only the packaging changes, and none of the adaptation logic lives in your app.

Template Lifecycle

Templates implement a managed lifecycle that handles complexity and compliance automatically:

1. Draft state: New templates begin in draft state, allowing experimentation without impacting production messaging or triggering external approval processes.

2. Validation and processing: When published, templates undergo automatic validation, entity processing, and format optimization before becoming available for message sending.

3. Approval integration: For channels requiring approval (WhatsApp via Meta, RCS via your RCS Sender Profile), the system automatically submits templates and tracks approval status, managing complex interaction with external platform APIs.

Templates for Developers

Applications should adopt a template-first approach by implementing template-driven messaging architectures. Your app should:

• Treat templates as contracts: Templates define the interface between app logic and message delivery, creating a stable contract that isolates business logic from messaging platform complexity.

• Provide dynamic variables: Applications provide data to templates rather than constructing messages directly, enabling consistent formatting and automated optimization.

• Implement channel-agnostic operations: Messaging code references template IDs and provides variable data, while the platform handles channel selection, formatting, and delivery optimization. This allows you to send messages to WhatsApp, SMS, RCS, and other channels with the same codebase.

To put this model to work, Working with Templates is the practical starting point for building and approving templates, and the template definition reference documents every field, limit, and status of the definition JSON. For how routing chooses the channel a template renders on, see Unified Messaging Intelligence.