Vonage Server SDK for Node.js: A Monorepo for SMS, Voice and Verify
Vonage API client for Node.js. API support for SMS, Voice, Text-to-Speech, Numbers, Verify (2FA) and more.
At a glance
- What is it?
- The Vonage Node SDK wraps the company's REST APIs in a TypeScript monorepo of 28 workspace packages. It is the right tool if you already send SMS or place calls through Vonage, and the wrong one if you want a carrier-neutral abstraction.
- Who is it for?
- Adopt it when Vonage is already your telephony provider and you want one typed client for SMS, Voice, Verify and Numbers instead of hand-rolled HTTP calls. Do not adopt it as a carrier-neutral layer: every package targets Vonage endpoints, and Dispatch, External Accounts and the conversion helper are not available.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 19, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the Vonage Node SDK actually solves
Sending an SMS, placing a voice call and running a two-factor check against Vonage means three different REST endpoints, three payload shapes and three sets of error codes. The SDK collapses that into one constructed client with namespaced methods. The README's own example is a single call, `vonage.sms.send`, taking `to`, `from` and `text`.
The audience is narrower than the package description suggests. You need a Vonage account, and the README points to vonage.com for signup. Nothing in the repository suggests a self-hosted or offline mode, because every method is a thin wrapper over a hosted API. If you are building an SMS gateway that talks to several carriers, this is a client for one of them, not a routing layer.
The monorepo layout and what it means for your dependency tree
The repository is a private workspace root named `@vonage/server-sdk-monorepo` with `workspaces` listing 28 packages, including `packages/sms`, `packages/voice`, `packages/verify`, `packages/verify2`, `packages/messages`, `packages/numbers`, `packages/auth`, `packages/jwt`, `packages/vetch` and `packages/server-client`. The published `@vonage/server-sdk` package is the aggregate entry point that re-exports them.
That split is the most consequential design decision in the project. You can depend on `@vonage/sms` alone and skip the video and meetings code, or take the umbrella package and accept the wider tree. The README documents the constructor as taking `credentials` from `@vonage/auth` and `options` from `@vonage/server-client`, which is how the shared HTTP layer stays out of each product package.
One detail worth noting: the root `package.json` declares `"type": "module"` and the version field reads `3.20.1` while the latest release is v3.30.0. The root version is not the published SDK version, so do not read it as the version of the package you install.
Installing the SDK and sending your first SMS
The README gives two install paths. With npm it is a single package, and with Yarn the same package name. There is no separate CLI to install and no build step for consumers.
npm install @vonage/server-sdkAfter install, the README's constructor example imports `Vonage` from the package and instantiates it with a credentials object and an options object.
const { Vonage } = require('@vonage/server-sdk');
const vonage = new Vonage(credentials, options);What goes inside `credentials` is not in the README. It points to the `@vonage/auth` README for the available options, so that is the file to open before your first run. The second argument, `options`, is defined by `@vonage/server-client`.
The README states that most methods returning API results use Promises, so the first real call is an awaited send. The example below is the one the README gives, with `to`, `from` and `text` as the payload keys.
const resp = await vonage.sms.send({
to: '15552220000',
from: '15559992222',
text: 'This is a test',
});The README does not document the shape of `resp`, so log it rather than assuming a field name. If you want runnable end-to-end code, the README points to the Vonage Node Quickstarts repository at `Vonage/vonage-node-code-snippets` rather than shipping samples in this repository.
Coverage gaps: Dispatch, External Accounts and the removed conversion helper
The supported-API table is the most useful page in the README, because it marks two APIs as unsupported: Dispatch and External Accounts, both listed as Beta. If your architecture depends on either, this SDK will not carry you and you will be writing raw HTTP against the Vonage endpoints.
The V2 migration table is the second place where functionality disappears. `vonage.conversion` is marked REMOVED with no replacement noted. Several other V2 functions moved rather than vanished: `vonage.conversation` went to the Conversations package, `vonage.app` to Applications, `vonage.files` to ServerClient, `vonage.message` to SMS, `vonage.generateJwt` to JWT, and `vonage.generateSignature` to both SMS and Voice. A 2.x codebase will need those call sites rewritten, and the table is the checklist.
There is also a status column that matters more than the support checkmarks. Meetings API and Proactive Connect API are marked Deprecated while still supported, Audit, Media, Reports and Sub Accounts are Beta, and Redact API is Developer Preview. A green check means the SDK wraps the endpoint, not that the endpoint is stable.
Verify or Verify v2, and the Network APIs that are opt-in
Two separate packages exist for two-factor: `packages/verify` and `packages/verify2`. The table lists both as General Availability. That is a fork in the road for new work, and the README does not tell you which to pick. You have to read both package READMEs and decide based on the Vonage API you have provisioned, not on the SDK's recommendation, because the SDK does not make one.
Network APIs work differently from everything else here. Number Verification and SIM Swap are supported but the README states they are opt-in, with their own packages `packages/network-number-verification` and `packages/network-sim-swap` and a separate `packages/network-client`. The word opt-in is doing real work: these are not loaded through the same default path as SMS or Voice, so check the package README before assuming `new Vonage(...)` gives you access to them.
Where this SDK is the wrong choice
The clearest failure mode is provider lock-in by construction. Every method targets a Vonage endpoint, and the credential model comes from `@vonage/auth`. If you need to switch carriers under load, or route a message through whichever aggregator is cheapest for a destination, this SDK is a dead end because it has no abstraction over the transport. You would be wrapping the wrapper.
The second case is the deprecated surface. Meetings and Proactive Connect are marked Deprecated in the table. Building a new integration on a deprecated API through a supported SDK still puts you on a deprecated API.
The third is versioning discipline. The root `package.json` version and the latest release tag do not agree, and the README's badge links point at a `3.x` branch while the default branch is `main`. Neither is a defect on its own, but it means you should pin the published package version you install rather than trusting a branch name or a repository file to tell you what you are running.
How it compares with Twilio's Node helper library
The obvious alternative is the Twilio Node helper library, and the difference is structural rather than cosmetic. Twilio ships one package with a client that exposes resources from a single namespace, so `twilio.messages.create(...)` and `twilio.calls.create(...)` live in the same import. Vonage splits the same surface across workspace packages and re-exports them through `@vonage/server-sdk`, which lets you install `@vonage/sms` without the video and meetings code.
That granularity is the actual trade-off. The Vonage layout gives you a smaller dependency tree per product and clearer ownership boundaries between `packages/auth`, `packages/server-client` and the product packages. It also means more places to look when a call fails, because the HTTP behaviour lives in `server-client` and the credential behaviour lives in `auth`, not in the package you called. Twilio's single-package model is easier to reason about on day one and harder to trim later. Neither is a quality difference; it is a packaging philosophy, and the Vonage one rewards teams that only need one or two products.
Licence, maintenance and what an upgrade costs
The repository is licensed Apache-2.0, and the root `package.json` states `"license": "Apache 2.0"`. Apache-2.0 includes an express patent grant, which matters if you are shipping the SDK inside a commercial product; the usual obligations around notices and attribution still apply, and this is a description of the licence text rather than legal advice.
Maintenance is visible in the release cadence: v3.30.0 on 2026-09-01, v3.29.0 on 2026-07-29 and 3.28.0 on 2026-06-29, roughly monthly. The last push to the repository was on 2026-09-14. There is a `MAINTENANCE.md` and a `RELEASES.md` at the repository root, and those are the files to read for the project's own policy rather than inferring one from commit dates.
The upgrade cost is concentrated in the V2 migration table. If you are on 2.x, budget for rewriting every call site listed there, including the `vonage.conversion` calls that have no replacement. If you are already on 3.x, the monthly releases suggest small increments, but the README does not document a deprecation window or a rollback path for the SDK itself, so pin your version in `package.json` and read the changelog before bumping.
Editorial conclusion
Adopt it when Vonage is already your telephony provider and you want one typed client for SMS, Voice, Verify and Numbers instead of hand-rolled HTTP calls. Do not adopt it as a carrier-neutral layer: every package targets Vonage endpoints, and Dispatch, External Accounts and the conversion helper are not available. Before you commit, check the supported-API table for the product you need, confirm whether you want the legacy Verify API or the Verify v2 API, and read the V2 migration table if you are upgrading from a 2.x codebase.
Frequently asked questions
Does Vonage have an open API?
The SDK is an Apache-2.0 licensed client for Vonage's hosted APIs, and the README points to developer.vonage.com for full API documentation. The APIs themselves are hosted services that require a Vonage account, so the client is open source while the endpoints it calls are not something you run yourself.
Is Vonage open source?
This SDK is open source under Apache-2.0, with the source in the Vonage/vonage-node-sdk repository and a Contributor Covenant code of conduct. The license covers the client library, not the Vonage platform behind it.
Is Nexmo vonage?
The repository carries the `nexmo` topic alongside `vonage`, and the README's V2 migration table describes V2 functions being ported into their own packages, which is the rename showing up in the code. The README does not otherwise explain the history, so treat the topic tag and the migration table as the evidence in this material.
Community notes