Compatibility reference for existing integrations. New integrations should use /api/ext/v3/messageTemplates/send for both single and multiple recipients.

This retained single-send query route accepts whatsappNumber or a supported target; a non-whitespace target takes precedence. Business-scoped identity targets depend on account support. Supply the required broadcast_name, select the approved WATI template with template_name, and supply its named parameter values in the body's parameters array as {name,value} entries. Use the names from the actual WATI template mapping; array position alone is not the binding contract. Use optional channel_number only as supported by this legacy operation.

Inspect the HTTP response and the legacy business result separately. Acceptance does not establish delivery. Retain correlation and message/campaign identifiers, and reconcile uncertain outcomes before resending. Neither a repeated request label nor a caller correlation ID is a general request-level idempotency guarantee.

The similarly named sendTemplateMessage/{whatsappNumber} action has different role support; do not assume scoped tokens work with both routes. See the template payload and V1 migration guide and token lifecycle guide.

Permissions

For API access tokens and OIDC tokens, satisfy at least one of: api, wati_integration:write, messagetemplate:write. API access tokens may satisfy a listed scope through the configured scope hierarchy; OIDC tokens are checked against their scope claims. Legacy JWT authentication does not use this scope check. Authentication, role, tenant, and applicable feature or plan checks still apply. For HTTP 403, check the credential type, applicable scopes, roles, and workspace access; 403 does not always mean a missing scope. Authentication/authorization failures do not guarantee a JSON response body.