Vonage

Vonage's API surface has evolved through multiple generations. The Messages API (v1) is the modern recommended path — POST to /v1/messages with channel-specific payloads (sms, whatsapp, messenger). The older SMS API at /sms/json still works but lacks multi-channel support. Voice API uses NCCO (Nexmo Call Control Objects) — JSON-based call flow descriptions that agents construct and serve from webhook endpoints. Video API uses sessions and tokens for WebRTC. The API design is REST-oriented with JSON throughout. Authentication varies by API: some use API key + secret as query params, others use JWT. This inconsistency adds integration friction. Pagination on list endpoints uses cursor-based tokens.

SMS API returns JSON with status codes per message segment — status 0 means accepted, non-zero values indicate specific failures (1=throttled, 2=missing params, 4=invalid credentials, 6=invalid message). Messages API returns HTTP status codes (200, 400, 401, 429) with structured error bodies. Delivery receipts arrive asynchronously via webhook — agents cannot determine final delivery status from the send response alone. Rate limits vary by API and account level; 429 responses include Retry-After headers. Voice call failures surface through webhook events. Global SMS delivery rates vary significantly by country and carrier — agents sending internationally should expect non-trivial failure rates on certain corridors. Error documentation is good but scattered across API-specific guides.

Vonage (formerly Nexmo) provides a broad CPaaS surface: SMS, voice, video, and multi-channel messaging. For agents, the Messages API is the most relevant — it unifies SMS, WhatsApp, Facebook Messenger, and Viber under a single send endpoint, simplifying multi-channel notification workflows. The Verify API handles phone number verification flows autonomously. Number Insight API provides carrier and porting data useful for fraud prevention agents. The main challenge is the webhook-heavy architecture: most Vonage interactions require agents to receive inbound HTTP callbacks for delivery receipts, inbound messages, and call events, which means agents need a publicly reachable endpoint. The developer experience has been uneven since the Ericsson acquisition — some docs reference Nexmo patterns, some use the newer Vonage branding.

Vonage uses two auth mechanisms depending on the API: API key + secret (for SMS, Verify, Number Insight) and JWT with application private key (for Voice, Messages, Video). This dual-auth model is the biggest friction point for agents — they must maintain two credential types and know which API uses which. Application creation in the dashboard generates a private key file for JWT signing. The JWT has a short TTL and must be regenerated per request or session. API key + secret are passed as query parameters (not headers) on older APIs, which is less secure. No OAuth support for third-party access. Dashboard supports team members with role-based access. Subaccounts available for organizational isolation.

The developer portal at developer.vonage.com covers all APIs with quickstart guides, code examples, and API reference. Server SDKs exist for Node, Python, Ruby, PHP, Java, and .NET. Code examples are generally current and functional. The main documentation challenge is navigational: the transition from Nexmo branding left some guides referencing old endpoints, dashboard locations, or library names. The API reference uses OpenAPI specs with Try It functionality. Vonage Community (formerly Nexmo Community) provides blog posts and tutorials. Dashboard UX for application and number management is functional but not streamlined. For agents, the quickest path is the Messages API quickstart + the relevant server SDK — skip the older SMS API docs unless backward compatibility is needed.