Reference · built on requestConnectorMessaging & notifications

Vonage

SMS, MMS, RCS, WhatsApp, Viber, and Messenger sending with inbound and status webhooks through the Vonage Messages API.

Request VonageAsk about this listing

About

The Vonage Messages API sends and, for most channels, receives messages over SMS, MMS, RCS, WhatsApp, Facebook Messenger, Viber Business Messages, and Email in beta. One endpoint, POST /v1/messages on api.nexmo.com or a regional host, takes the same request shape for every channel. A Message Status webhook reports submitted, delivered, rejected, or undeliverable, and an Inbound Message webhook delivers replies.

Through Fibric, an operator drafts a customer message on the channel you choose, with a client_ref and an optional failover to SMS, and proposes it. You approve. The send happens once and its status history stays on the record.

This is a reference listing. It documents what Fibric would read from Vonage and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

What it reads

  • Inbound messages from customers on SMS, MMS, RCS, WhatsApp, Messenger, and Viber through the Inbound Message webhook
  • Message status changes of submitted, delivered, rejected, and undeliverable through the Message Status webhook, keyed by message_uuid and client_ref
  • Failover details and usage on each status event through its workflow and usage objects
  • The 202 response to a send with its message_uuid, and 402, 422, or 429 responses when a send is refused
  • Inbound WhatsApp context such as user profile, referral, and order information, plus WhatsApp and RCS button replies

Proposed actions

  • Target capability: propose an SMS or MMS through POST /v1/messages with channel, message_type, to, from, text, ttl, and client_ref
  • Target capability: propose a WhatsApp template, text, image, file, or reaction message, or an RCS card or carousel, through the same endpoint
  • Target capability: propose a failover chain, so a WhatsApp or RCS message falls back to SMS if it fails
  • Target capability: propose marking an inbound WhatsApp or RCS message read, or revoking an outbound RCS message, through PATCH /v1/messages/{message_uuid}

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Send a delivery ETA on the customer's channel

    A driver's ETA becomes a proposed WhatsApp or RCS message with SMS failover. You approve; the status webhook records submitted and delivered against the stop.

    With ETA Notice

  • Confirm appointments and read the replies

    The operator drafts a reminder with a client_ref tied to the booking and proposes it. A reply through the Inbound Message webhook lands on the same record for a person to act on.

    With Appointment Reminder

  • Tell a customer about a backorder

    When an order line cannot ship, the operator proposes an SMS with the new date. Rejected or undeliverable statuses are surfaced so a person can try another channel.

    With Backorder Notice

  • Answer where-is-my-order by text

    An inbound SMS asking about an order is matched to the order, and a proposed reply with the tracking status is drafted for approval.

    With WISMO Deflection

What it needs

  • A Vonage API account with an API key and secret from the API Dashboard
  • A Vonage Application with inbound and status webhook URLs set, plus its application id and private key for JWT auth
  • A Vonage number or sender id per channel; WhatsApp, Messenger, and Viber accounts are linked through the External Accounts API
  • 10 DLC brand and campaign registration before sending SMS or MMS from a US 10-digit long code
  • Phone numbers as E.164 digits with no leading + or 00
Authentication
Basic authentication with the account API key and secret, or a JWT signed with a Vonage Application's private key and application id and sent as a Bearer token; Vonage recommends JWT beyond the Messages Sandbox.

Limits

  • 75 requests per second per API key by default; above that the API returns 429
  • A 202 means accepted by Vonage, not delivered; channel or network rejections arrive later as a rejected status
  • SMS text is limited to 3200 characters and client_ref to 100; delivery is attempted for 72 hours by default, less on many operators
  • Outbound WhatsApp status cannot be changed through PATCH; only inbound read receipts and RCS revocation are supported

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Vonage

Questions and answers

Which channels can receive inbound messages?
SMS, MMS, RCS, WhatsApp, Facebook Messenger, and Viber Business Messages deliver replies to the Inbound Message webhook set on your Vonage Application. Which media types arrive inbound varies by channel; SMS carries text only.
How do I know a message was delivered?
The send returns 202 with a message_uuid. Delivery is reported later to the Message Status webhook, per message if you set webhook_url in the request, with status submitted, delivered, rejected, or undeliverable, a timestamp, and your client_ref. The legacy SMS API uses separate Delivery Receipts instead.
Basic auth or JWT?
Both work. Basic uses the API key and secret and authenticates at account level. A JWT is generated from a Vonage Application's id and private key and authenticates at application level, which is needed for application webhooks and Secure Inbound Media. Vonage recommends JWT beyond the Messages Sandbox.
Ask about Vonage

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Vonage through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy