🚀 Feature: First-class Gupshup WhatsApp (template) provider for SMS channel

[itsarraj]

🔖 Feature description

Novu’s SMS channel currently supports Gupshup for classic SMS. Many teams use Gupshup’s WhatsApp Business API with template messages (POST https://api.gupshup.io/wa/api/v1/template/msg), which is a different integration shape (template id + params, src.name, etc.).

We implemented a dedicated SMS provider (e.g. gupshup-whatsapp) that:

• Sends WhatsApp template messages via Gupshup’s template endpoint.
• Maps credentials consistently with Gupshup’s docs: API key, source number, app name (src.name).
• Allows passing templateId / templateParams from the trigger payload (merged into provider customData on the worker) so backend triggers match how we used to call Gupshup directly.

We also wired it through the usual Novu surfaces: shared provider registry, framework schema entry, @novu/providers implementation + tests, SMS factory/handler, and dashboard integration listing (including provider icon asset).

🎤 Why is this feature needed ?

• Single platform: Teams want WhatsApp template delivery inside Novu workflows instead of maintaining a separate Gupshup integration in each backend service.
• Parity with existing Gupshup SMS: Gupshup is already a first-class SMS provider; WhatsApp via Gupshup is a natural extension for the same vendor.
• Trigger ergonomics: Template id and params often live on the event payload from application code; supporting that path reduces friction vs. only step overrides.

Example payload (conceptually):

{
  "phone": "+919xxxxxxxxxx",
  "templateId": "<uuid>",
  "templateParams": ["param1", "param2", "param3"]
}

✌️ How do you aim to achieve this?

• New provider id (e.g. SmsProviderIdEnum.GupshupWhatsapp / gupshup-whatsapp) with credentials: apiKey, from (source), senderName (app name for src.name).
• Provider class in @novu/providers that POSTs application/x-www-form-urlencoded to Gupshup’s template URL with channel=whatsapp, template JSON { id, params }.
• Worker: for this provider only, merge known payload keys (templateId, template_params, nested template, etc.) into customData before calling the SMS handler.
• Unit tests on the provider (request shape / headers / body).
• Dashboard: show the provider in the SMS integration list and ship public/images/providers/light/square/gupshup-whatsapp.svg (or equivalent) so the icon resolves like other providers.

🔄️ Additional Information

• Alternatives considered: Using the generic SMS provider or a custom bridge; both add operational complexity compared to a built-in Gupshup WhatsApp provider.
• Scope note: Our changes were driven by our production needs (template send path). We have not implemented full Gupshup inbound webhooks or a separate “Chat” channel for WhatsApp unless you want that as a follow-up; the issue can be titled/narrowed to “template send” if you prefer.
• Contribution: If the maintainers agree with the design (provider id, credential keys, payload → customData behavior), we are willing to open a PR from our fork and iterate on naming, docs, and any security review you require.

👀 Have you spent some time to check if this feature request has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Contributing Guidelines

Are you willing to submit PR?

Yes I am willing to submit a PR!

[linear]

NV-7305

[itsarraj]

assign me