🔖 Feature description
Add ValueFirst (https://www.vfirst.com) as a native SMS provider under packages/providers/src/lib/sms/valuefirst/, following the same pattern as existing providers such as termii and firetext.
ValueFirst exposes an XML-based HTTPS API for sending SMS. The provider requires Bearer token authentication (7-day TTL, auto-refreshed) and supports delivery report (DLR) webhooks via HTTP callback.
Credentials needed
username — ValueFirst account username
password — ValueFirst account password
from — Sender ID (max 11 alphanumeric chars)
API endpoint: https://api.myvfirst.com/psms/servlet/psms.Eservice2
DLR status values to map: DELIVERED, NOT_DELIVERED, QUEUED, SENT, FAILED, REJECTED
🎤 Why is this feature needed ?
ValueFirst is one of the most widely adopted CPaaS providers in India, used extensively across government platforms, banking, healthcare, and enterprise systems. Several Novu users building products for the Indian market are currently blocked from using ValueFirst natively and are forced to work around the limitation using the generic-sms provider with a custom HTTP adapter — adding unnecessary infrastructure overhead.
Concrete use case:
We are building a citizen-facing complaint resolution system on the
DIGIT urban governance platform (used by multiple state governments in
India). Notifications such as complaint acknowledgements, status updates,
and resolution confirmations need to be delivered via SMS using ValueFirst,
which is the mandated SMS gateway for several government tenants.
India-specific requirement — DLT compliance:
TRAI (India's telecom regulator) mandates that every commercial SMS carry
a registered DLTTEMPLATEID, DLTCONTENTTYPE, and ENTITYID. A native
ValueFirst provider would allow these fields to be passed correctly through
Novu's _passthrough mechanism, which is not straightforward with the
current generic-sms workaround.
Adding this provider would give Indian Novu users a first-class integration
with no custom adapter code required.
✌️ How do you aim to achieve this?
I want this feature to introduce a new valuefirst provider package under
packages/providers/src/lib/sms/valuefirst/ with the following structure:
Files to create:
valuefirst.provider.ts — core provider implementing ISmsProvider
valuefirst.provider.spec.ts — unit tests
index.ts — barrel export
Implementation plan:
-
Authentication — POST to ValueFirst's token endpoint
(https://api.myvfirst.com/psms/api/messages/token?action=generate)
using Basic Auth, cache the Bearer token with a 7-day TTL, and
auto-refresh before expiry.
-
sendMessage() — Build a ValueFirst XML payload and POST it to
https://api.myvfirst.com/psms/servlet/psms.Eservice2 with
Authorization: Bearer <token>. Extract the message ID from the
XML response.
-
getStatus() — Map ValueFirst DLR statuses (DELIVERED,
NOT_DELIVERED, QUEUED, SENT, FAILED, REJECTED) to
SmsEventStatusEnum.
-
parseEventBody() — Parse ValueFirst's DLR webhook callback
(query-string format) into a standardised ISmsWebhookBody.
-
Register the provider in SmsProviderIdEnum and export it
from the SMS providers index.
I am willing to submit a PR implementing the above. The implementation
would closely follow the pattern of termii and firetext providers
already in the codebase.
🔄️ Additional Information
I tried using the existing generic-sms provider as a workaround by
pointing its baseUrl at a custom Node.js adapter that translates
Novu's JSON payload into ValueFirst's XML API format. While this works,
It requires maintaining an extra adapter service, managing the Bearer token
rotation outside of Novu, and handling DLR webhook forwarding manually.
A native provider would eliminate all of this overhead and make
ValueFirst a first-class integration available directly from the
Novu dashboard — consistent with how Twilio, Termii, and other
Providers work today.
References:
👀 Have you spent some time to check if this feature request has been raised before?
🏢 Have you read the Code of Conduct?
Are you willing to submit PR?
None
🔖 Feature description
Add ValueFirst (https://www.vfirst.com) as a native SMS provider under
packages/providers/src/lib/sms/valuefirst/, following the same pattern as existing providers such astermiiandfiretext.ValueFirst exposes an XML-based HTTPS API for sending SMS. The provider requires Bearer token authentication (7-day TTL, auto-refreshed) and supports delivery report (DLR) webhooks via HTTP callback.
Credentials needed
username— ValueFirst account usernamepassword— ValueFirst account passwordfrom— Sender ID (max 11 alphanumeric chars)API endpoint:
https://api.myvfirst.com/psms/servlet/psms.Eservice2DLR status values to map:
DELIVERED,NOT_DELIVERED,QUEUED,SENT,FAILED,REJECTED🎤 Why is this feature needed ?
ValueFirst is one of the most widely adopted CPaaS providers in India, used extensively across government platforms, banking, healthcare, and enterprise systems. Several Novu users building products for the Indian market are currently blocked from using ValueFirst natively and are forced to work around the limitation using the
generic-smsprovider with a custom HTTP adapter — adding unnecessary infrastructure overhead.Concrete use case:
We are building a citizen-facing complaint resolution system on the
DIGIT urban governance platform (used by multiple state governments in
India). Notifications such as complaint acknowledgements, status updates,
and resolution confirmations need to be delivered via SMS using ValueFirst,
which is the mandated SMS gateway for several government tenants.
India-specific requirement — DLT compliance:
TRAI (India's telecom regulator) mandates that every commercial SMS carry
a registered
DLTTEMPLATEID,DLTCONTENTTYPE, andENTITYID. A nativeValueFirst provider would allow these fields to be passed correctly through
Novu's
_passthroughmechanism, which is not straightforward with thecurrent
generic-smsworkaround.Adding this provider would give Indian Novu users a first-class integration
with no custom adapter code required.
✌️ How do you aim to achieve this?
I want this feature to introduce a new
valuefirstprovider package underpackages/providers/src/lib/sms/valuefirst/with the following structure:Files to create:
valuefirst.provider.ts— core provider implementingISmsProvidervaluefirst.provider.spec.ts— unit testsindex.ts— barrel exportImplementation plan:
Authentication — POST to ValueFirst's token endpoint
(
https://api.myvfirst.com/psms/api/messages/token?action=generate)using Basic Auth, cache the Bearer token with a 7-day TTL, and
auto-refresh before expiry.
sendMessage() — Build a ValueFirst XML payload and POST it to
https://api.myvfirst.com/psms/servlet/psms.Eservice2withAuthorization: Bearer <token>. Extract the message ID from theXML response.
getStatus() — Map ValueFirst DLR statuses (
DELIVERED,NOT_DELIVERED,QUEUED,SENT,FAILED,REJECTED) toSmsEventStatusEnum.parseEventBody() — Parse ValueFirst's DLR webhook callback
(query-string format) into a standardised
ISmsWebhookBody.Register the provider in
SmsProviderIdEnumand export itfrom the SMS providers index.
I am willing to submit a PR implementing the above. The implementation
would closely follow the pattern of
termiiandfiretextprovidersalready in the codebase.
🔄️ Additional Information
I tried using the existing
generic-smsprovider as a workaround bypointing its
baseUrlat a custom Node.js adapter that translatesNovu's JSON payload into ValueFirst's XML API format. While this works,
It requires maintaining an extra adapter service, managing the Bearer token
rotation outside of Novu, and handling DLR webhook forwarding manually.
A native provider would eliminate all of this overhead and make
ValueFirst a first-class integration available directly from the
Novu dashboard — consistent with how Twilio, Termii, and other
Providers work today.
References:
termii,firetext👀 Have you spent some time to check if this feature request has been raised before?
🏢 Have you read the Code of Conduct?
Are you willing to submit PR?
None