Introduction

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

Vonage's Voice API allows you to create and manage high-quality voice operation applications on the cloud, such as IVR, WebRTC and PSTN calling. Voice is a HTTP-based RESTful API. It is accessed over HTTPS combined with OAuth2.0 for extra security. Request and response bodies follow the JSON format to make the exchange of information fast, easy and reliable.


API specification

Test the API on SwaggerHub


Base URL

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


Conceptual model

Conceptual model


Definitions

Conversation, leg, conference

Communication can be 1-to-1 or 1-to-n from or to the Vonage platform. While 1-to-1 calls are known as a leg, 1-to-n calls are known as a conversation. Each call connected to a conversation is its own leg.

NCCO

A Nexmo Call Control Object (NCCO) is a JSON array that you use to control the flow of a Voice API call. For your NCCO to execute correctly, the JSON objects must be valid.

The Call event model is asynchronous. A static or dynamically created NCCO script provides the business logic for your Call. When a Call is placed to your number, Vonage (formerly Nexmo) makes a synchronous request to the webhook endpoint you set as the answer_url for your number and retrieves the NCCO object that controls the Call.

Extended information regarding NCCOs can be found in our NCCO reference page.

Webhook

Method to augment or alter the behavior of your application via user-defined HTTP callbacks. In your case webhook defines the behavior of your application.

DTMF

Dual Tone Multi Frequency (DTMF), is a form of signaling used by phone systems to transmit the digits 0-9 and the * and # characters.

Text to speech

Vonage uses text to speech engines to allow you to play machine generated speech in your calls. This feature can be added via NCCOs with the use of talk action or by making a put request on an in-progress call. There are 23 languages available with different styles and genders.

Recording

Vonage's Voice API offers the ability to record call audio in several ways:

SIP Trunk

To use Session Initiation Protocol (SIP), see the SIP documentation page.


API workflow

API workflow


Features

  • Scales with existing web solutions.
  • Easy to configure.
  • Records and stores any call.
  • Conference calls.
  • Text to speech messages in 23 languages.


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...

The API is divided into 2 groups of resources:

  • Application: Vonage App Management resource. Allows CRUD on applications.
  • Voice: Voice call management resource. Allows CRUD on the call.

Create the Vonage Application

Remember the application UUID, because it will be needed to make calls.

SwaggerHub:

  1. Select POST /applications.
  2. Click 'Try out'.
  3. Edit the request body by filling the name and answer_url.
  4. Click 'Execute'.
  5. Check the response code and message.

Postman:

  1. Click on (POST) Create new application resource.
  2. Fill the name and answer_url.
  3. Click 'Send'.
  4. Check the response code and message.

Create a call

SwaggerHub:

  1. Select POST /voice/calls.
  2. Click 'Try out'.
  3. Update the ApplicationId header with your application identifier.
  4. Edit the request body by filling to, from and answer_url fields.
  5. Click 'Execute'.
  6. Check the response code and message.

Postman:

  1. Click on (POST) Create an outbound call.
  2. Update the Headers section by filling theApplicationId` field. 3.. Update the body fields.
  3. Click 'Send'.
  4. Check the response code and message.


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