Introduction

Nexmo is now called Vonage, but there are still references to Nexmo in our URLs, code snippets and message templates.

With Vonage's (formerly called Nexmo) SMS API, you can send and receive text messages. The API is a secure gateway to Nexmo's bulk SMS service for customer messaging.


API specification

Test the API on SwaggerHub


Base URL

https://api-prd.kpn.com/communication/nexmo/sms


Conceptual model

Conceptual model


Definitions

Webhook

A webhook is an HTTP POST callback implemented by you, that can be called by another system when an event is triggered on that system to notify you. You will need to make the address of your webhook known on the other system to make it work.

SMS

SMS stands for Short Message Service and is the most widely used type of text messaging. With an SMS, you can send a message of up to 160 characters to another device.


API workflow

API workflow


Requirements

For receiving an SMS, this API depends on Vonage's Phone Numbers API, which you can use to create a virtual number. You need to apply for production in our portal for that API too.


Features and constraints

Features

  • Send SMS: You can send SMS using mobile number, content and sender parameters in the request body of the SMS API.
  • Receive SMS: SMS using this API is easy. In order to do so, you'll need to create a webhook endpoint. Then you should register it using the SMS API. After you have registered your webhook endpoint/callback URL you can send an SMS using the mobile number, content, and sender parameters in the request body and selecting the yes option in the ‘inbound’ header of the SMS API. Inbound messages sent by SMS recipient will be delivered to this registered webhook.

Constraints


Getting started

Make sure you've read Getting Started for more info on how to register your application and start trying out our APIs.

Authentication

The API follows the KPN Store API Authentication Standard to secure the API. It includes the use of OAuth 2.0 client_id and client_secret to receive an access token.

Go to the Authentication tab on top of this page to find out how to:

  • Authenticate to an API using cURL.
  • Authenticate to an API on Swaggerhub.
  • Import Open API Specifications (OAS), also called Swagger files into Postman.


How to...

Send SMS

SwaggerHub:

  1. Select POST /send.
  2. Click 'Try it out'.
  3. Edit the parameters by filling out from, to, text and other fields at will.
  4. Click 'Execute'.
  5. Check the response code and message.

Postman:

  1. Select (POST) Send SMS.
  2. Click the Body section of the request and provide values for the following keys: from, to and text. Other advanced keys can be filled at will.
  3. Click 'Send'.
  4. Check the response code and message.
^^Result example^^
{
  "message-count": "1",
  "messages": [
    {
      "to": "316*****",
      "message-id": "13000000*****",
      "status": "0",
      "remaining-balance": "*****",
      "message-price": "*****",
      "network": "20408"
    }
  ]
}

Receive an SMS

Handling inbound SMS with the API is easy. You just need to create a webhook endpoint and configure your number or account to point to the endpoint. If you are a test user then you can try inbound messaging using below using Register webhook endpoint. Otherwise, you should use the Phone Numbers API to search, buy and manage your virtual number. In order to use the Phone Numbers API you should take this App containing Phone Numbers API to production.

Register webhook endpoint

With a test application, you can try inbound messaging by registering your webhook against your own phone number you use for testing, without buying a virtual number. This is not applicable if you apply for production usage.

SwaggerHub:

  1. Select POST /register.
  2. Click 'Try it out'.
  3. Edit the parameters by filling out to and callback_url.
  4. Click 'Execute'.
  5. Check the response code and message.

Postman:

  1. Select (POST) Register callback URL to webhook for incoming messages.
  2. Click the Body section of the request and provide values for the following keys: to and callback_url.
  3. Click 'Send'.
  4. Check the response code and message.
^^Result example^^
{
  "message": "Your callback url is registered."
}

Update a number

If you applied for production then you should manage your numbers using the Phone Numbers API. Under 'Update a number' you can register your webhook against your virtual number using the moHttpUrl parameter.

^^cURL request example^^
curl -X POST \
  'https://api-prd.kpn.com/communication/nexmo/phone-numbers/number/update' \
  -H 'authorization: Bearer access_token' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'country=NL&msisdn=447700900000&moHttpUrl=https://example.com:webhooks/inbound-sms'

SwaggerHub:

  1. Select POST /number/update.
  2. Click 'Try it out'.
  3. Edit the parameters by filling out country and msisdn. Also edit the other parameters, as mentioned in the above table, to your needs.
  4. Click 'Execute'.
  5. Check the response code and message.

Postman:

  1. Select (POST) Update a number.
  2. Click the Body section of the request and provide values for country and msisdn. Also edit the other parameters in the body, as mentioned in the above table, to your needs.
  3. Click 'Send'.
  4. Check the response code and message.
^^Result example^^
{
  "error-code":"200",
  "error-code-label":"success"
}

Send and receive SMS

Send an SMS. If you are using a test application then VirtualNumber will be your own number that you registered with your webhook. When you reply to the number then you will see the response in your webhook.

SwaggerHub:

  1. Select POST /send.
  2. Click 'Try it out'.
  3. Edit the parameters by filling out from (use your own number or the VirtualNumber), to, text and other fields at will.
  4. Click 'Execute'.
  5. Check the response code and message.

Postman:

  1. Select (POST) Send SMS.
  2. Click the Body section of the request and provide values for the following keys: from (use your own number or the VirtualNumber), to and text. Other advanced keys can be filled at will.
  3. Click 'Send'.
  4. Check the response code and message.
^^Result example^^
{
  "message-count": "1",
  "messages": [
    {
      "to": "316*****",
      "message-id": "13000000*****",
      "status": "0",
      "remaining-balance": "*****",
      "message-price": "*****",
      "network": "20408"
    }
  ]
}


Return codes

Code Description
200 Success.
201 Created.
202 Accepted.
302 Found. Link in location header.
400 Bad request.
401 Unauthorized.
403 Forbidden.
404 Not found.
405 Method not allowed.
412 Precondition failed.
429 Too many requests.
500 Internal server error.
502 Bad gateway.
503 Service unavailable.


HTTP response headers

The following tables display the standard response headers that are returned with each API response:

Standard response field name Description
sunset This field will be populated with the deprecation details. By default the value is n/a.
api-version Indicates the API version you have used.
quota-interval Used to specify an integer (for example, 1, 2, 5, 60, and so on) that will be paired with the quota-time-unit you specify (minute, hour, day, week, or month) to determine a time period during which the quota use is calculated.
For example, an interval of 24 with a quota-time-unit of hour means that the quota will be calculated over the course of 24 hours.
quota-limit Number of API calls an user can make within a given time period.
If this limit is exceeded, the user will be throttled and API requests will fail.
quota-reset-UTC All quota times are set to the Coordinated Universal Time (UTC) time zone.
quota-time-unit Used to specify the unit of time applicable to the quota.
For example, an interval of 24 with a quota-time-unit of hour means that the quota will be calculated over the course of 24 hours.
quota-used Number of API calls made within the quota.
strict-transport-security The HTTP Strict-Transport-Security (HSTS) response header lets a web site tell browsers that it should only be accessed using HTTPS, instead of using HTTP. All present and future subdomains will be HTTPS for a maximum of 1 year and access is blocked to pages or sub domains that can only be served over HTTP including HSTS preload lists of web browsers.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.
Access control field name Description
access-control-allow-credentials Tells browsers whether to expose the response to frontend JavaScript samp when the request's credentials mode (Request.credentials) is include.
When a request's credentials mode (Request.credentials) is include, browsers will only expose the response to frontend JavaScript samp if the Access-Control-Allow-Credentials value is true. Boolean.
access-control-allow-origin Indicates whether the response can be shared with requesting samp from the given origin.
access-control-allow-headers Used in response to a pre-flight request which includes the Access-Control-Request-Headers to indicate which HTTP headers can be used during the actual request.
access-control-max-age Indicates how long the results of a pre-flight request (that is the information contained in the Access-Control-Allow-Methods and Access-Control-Allow-Headers headers) can be cached.
access-control-allow-methods Indicates which HTTP methods are allowed on a particular endpoint for cross-origin requests.
For example: GET, PUT, POST, DELETE.
content-length The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.
content-type The Content-Type entity header the client what the content type of the returned content actually is.

Mopinion feedback