Skip to main content

In short

  • Write {{key}} in the copy. At send time Notifique fills values from defaults, the contact, and request variables.
  • Contact keys: use name, email, phone. Prefer English for built-in keys.
  • Management and send use different scopes. See API Key scopes.

Channels on a template

Each template chooses which channels are active (1 to 9): sms, whatsapp, telegram, email, rcs, push, voice, instagram, whatsapp_call. In the API, use one root block per channel:
On send, channels must be a subset of enabledChannels. A requested but disabled channel returns 400 (TEMPLATE_CHANNEL_NOT_ENABLED).
Template CRUD uses { enabled, payload } with editor fields per channel (content, messageType, speakText, …). Message send APIs use to + type + payload — do not mix the two contracts.

Per-channel payloads (create / update)

{{…}} variables also apply inside nested RCS strings, push title/body, voice speakText, and Instagram content.

Variables in copy ({{…}})

Two sources merge on send:
  1. From the template: placeholders you typed. They need a value in variables or variableDefaults.
  2. From the contact: filled automatically when the recipient exists in the workspace (except Telegram-only recipients).
Priority order: template defaults → contact data → custom fields → request variables (wins).

Built-in contact keys

Prefer {{name}}. In some internal flows nome may be filled alongside name, but the stable API and editor contract is name. Send variables.nome only if your copy intentionally uses that key.
Telegram-only recipients (chat_id or @username): automatic name/email merge does not run. Fill via variables or defaults.

Accepted formats

  • Named: {{order}}variables: { "order": "123" }
  • Positional: {{1}}, {{2}} → keys "1", "2"
  • Custom fields: same CRM technical key, e.g. {{current_plan}}

Custom fields

Each field has a technical key (snake_case, e.g. current_plan). In the template: {{current_plan}} with the same key. Define them in the dashboard (Contacts → Custom fields) or via the Contacts API. After merge, values also apply to RCS, Push, and Voice.

Defaults (variableDefaults)

If the send does not provide a key, the template default is used before failing on a missing variable. Contact data and request variables can still override it. On create or update, if you send variableDefaults, also include the variables array listing every placeholder key used in the copy (including keys with defaults).

Marketing and preferences

For templates with category MARKETING:
  • marketingTopicId: ties the send to a communication topic
  • appendPreferencesLink (default true): the platform fills {{preferences_link}} per recipient
Outside marketing, preferences_link may be empty: do not rely on it as the only CTA.

Translations (localeTranslations)

You can store per-locale translations for fields of enabled channels. On send, the API picks copy based on the contact language preference when available. Placeholders {{…}} in translations must match the primary template.

Management via API

List query: page, limit, search (name).
The filter GET /v1/templates?channels=whatsapp_call is not yet supported in the backend. Use search or filter by enabledChannels in the response.
Minimal SMS-only example:
templates:* scopes are for management. On send, each channel needs its send scope (including voice:call for voice).

Official Meta templates (WHATSAPP_OFFICIAL)

POST /v1/templates and PATCH /v1/templates/:id use the same validations as the dashboard:
  • required media on header/carousel (META_TEMPLATE_MEDIA_REQUIRED)
  • carousel cards with the same structure (META_TEMPLATE_CAROUSEL_INCONSISTENT)
  • rich structure only on official templates (TEMPLATE_META_STRUCTURE_REQUIRES_OFFICIAL)
On send (POST /v1/templates/send or type: "template" on each channel route) with sk_live_, the API also validates Meta token, metaName, media and carousel before queueing when the channel is official WhatsApp. With sk_test_, those Meta gates do not run (see Sandbox).

Preview test (sandbox)

In the template editor (dashboard), use Template preview test with Sandbox destination:
  • The message appears in the workspace Sandbox inbox — no real provider and no billing
  • Enabled template channels fire with internal fictitious destinations (test phone, email, etc.)
  • For email, the editor also offers preview and the HTML compatibility checker before send
API (dashboard): POST /templates/:id/send-test with "sandbox": true and desired channels. Public API: POST /v1/templates/send with sk_test_ or with sk_live_ when all recipients are the workspace test destinations.
Response 202 with sandbox: true. Webhooks follow the normal flow with sandbox: true in data. Each channel route (POST /v1/sms/messages, /v1/email/messages, /v1/whatsapp/messages, etc.) accepts type: "template" + payload.templateId and fires only that channel, handy when you already use the native channel contract. The internal name may differ from metaName (Graph name). Without a resolvable metaNameMETA_TEMPLATE_NOT_FOUND. Full codes: Error responses (Meta Cloud / official templates accordion) and Official Meta templates. Full schemas: API reference on the Templates tab.

See also