Inspect HTTP status and the business result separately. Even when success is true, recipients can contain errors or requested recipients can be absent. Reconcile returned identifiers with the request before deciding what to retry; acceptance is not delivery confirmation. A timeout, connection loss or 5xx can leave an unknown outcome. Neither broadcast_name nor local_message_id establishes a request-level idempotency guarantee.

• HTTP 200 carries a business result; inspect success and error. A 200 can report a failed request. A successful result is not a delivery confirmation.
• To know if a message is failed, listen to the Template Message Failed webhook.
• To know if a message is sent successfully, listen to Delivered/Read/Reply webhooks.

Permissions

For API access tokens and OIDC tokens, satisfy at least one of: api, wati_integration:write, messagetemplatev3: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.

Each recipient must have a non-empty phone_number or target. A target may be a phone number, contact ID, or a BSUID when enabled for the workspace. When both are present, a non-whitespace target takes precedence. Select the channel with the top-level channel field. An unresolved or unavailable target may be absent from recipients; inspect the overall result and use delivery webhooks for the outcome.