Introduction

With the SMS API, anyone can build reliable SMS messaging services using our infrastructure. It is available as a free demo version too. Send some test SMS messages and experiment with the API before taking it into production. In your API Store account you can apply to take the SMS API into production. Bulk SMS is now supported.


API specification

Test the API on SwaggerHub


Base URL

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


Conceptual model

Conceptual model


Definitions

SMS

An abbreviation of Short Message Service. It's a service on mobile phones to send and receive short messages.


API workflow

API workflow


Features and constraints

Features

  • Send a text message to another mobile phone number.
  • Bulk messaging is now supported: multiple message can be sent to a single recipient, as well as a single message to multiple recipients. This combined features: multiple messages to multiple recipients.

Constraints

  • No images can be sent with SMS.
  • Messages longer than 160 characters will be sent as multiple SMS messages. Maximum message length is 1000 characters.
  • With this API, messages can only be sent to mobile phones registered in the Netherlands. So the country code is locked to +31. Also 097 range is allowed.
  • With bulk messaging, the maximum number of messages multiplied by number of recipients in a single API call is 200.
  • In sandbox mode, message length is capped to 160 chars. This limitation is of course lifted in the production version.

060xxxxxxx, 067xxxxxxx and 069xxxxxxx are not valid mobile numbers.


Getting started

Make sure you've read What's in it for you for more info on how to register and start testing 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 a single SMS

Send an SMS by calling the POST /send endpoint of the SMS API in Swaggerhub or Postman.

Keep in mind that messages can only be sent to Dutch mobile phones (country code +31).

Create your payload for the request using below snippet:

^^Request example^^
{
  "sender": "KPN API",
  "messages": [
    {
      "mobile_number": "06xxxxxxxx or +316xxxxxxxx",
      "content": "Hi from KPN!"
    }
  ]
}

The payload uses following parameters:

Parameter Description
sender A text that should resemble the sender's origin. This string can have a maximum length of 11 characters.
mobile_number The mobile phone number of the addressee. Use the country code +31 at the start.
content Put your message here. Long messages will be split into multiple SMS.

SwaggerHub:

  1. Select POST /send.
  2. Click Try it out.
  3. Edit the body parameter by providing the payload snippet above. In the payload change the content, mobile_number and sender to your own good. Make sure the content-type is set to application/json.
  4. Click Execute.
  5. Check the response code and message.

Postman:

  1. Select (POST) /send.
  2. In the Body section, set the type to raw and insert the payload snippet above. In the payload change the content, mobile_number and sender to your own good. Make sure the content-type is set to application/json.
  3. Click Send.
  4. Check the response code and message.

Result example:

^^Response example^^
{
  "document_id": "b4e905d4-774c-4c83-8360-01427e17a33a",
  "status": "OK"
}

Sending bulk SMS's

Sending bulk SMS's uses the same endpoint as a single SMS: the POST /send endpoint of the SMS API in Swaggerhub or Postman. Bulk SMS's are multidimensional, which means that you can:

  • send a single SMS to multiple recipients,
  • send multiple SMS's to a single recipient,
  • a combination of these two options; send multiple SMS's to multiple recipients.

Keep in mind that messages can only be sent to Dutch mobile phones (country code +31).

Example of a payload for the request with a single SMS being send to multiple recipients:

^^Request example^^
{
  "sender": "KPN API",
  "messages": [
    {
      "mobile_number": "06xxxxxxxx,+316yyyyyyyy,06zzzzzzzz",
      "content": "Hi from KPN!"
    }
  ]
}

Example of a payload for the request with a multiple SMS's being send to multiple recipients:

^^Request example^^
{
  "sender": "KPN API",
  "messages": [
    {
      "mobile_number": "06xxxxxxxx",
      "content": "Hi from KPN!"
    },
    {
      "mobile_number": "+316xxxxxxxx",
      "content": "Hello there."
    },
    {
      "mobile_number": "06xxxxxxxx,06yyyyyyyy,+316zzzzzzzz",
      "content": "Till we meet again."
    }
  ]
}

Please keep in mind that the maximum message length is 1000 characters. Maximum messages times recipients in one API call is capped to 200 messages.

You will be charged for every SMS you send to a recipient. In the example above where one of the messages is sent to 3 recipients, will be charged as 1 + 1 + 3*1 = 5 SMS's.

This will also work in your sandbox. Feel free to test this, but be aware that you have a limited quota of 25 messages for testing purposes.

The payload uses following parameters:

Parameter Description
sender A text that should resemble the sender's origin. This string can have a maximum length of 11 characters.
mobile_number The mobile phone number(s) of the addressee(s). Use the country code +31 at the start.
content Put your message here. Long messages will be split into multiple SMS.

SwaggerHub:

  1. Select POST /send.
  2. Click Try it out.
  3. Edit the body parameter by providing the payload snippet above. In the payload change the content, mobile_number and sender to your own good. Make sure the content-type is set to application/json.
  4. Click Execute.
  5. Check the response code and message.

Postman:

  1. Select (POST) /send.
  2. In the Body section, set the type to raw and insert the payload snippet above. In the payload change the content, mobile_number and sender to your own good. Make sure the content-type is set to application/json.
  3. Click Send.
  4. Check the response code and message.

Result example:

^^Response example^^
{
  "document_id": "b4e905d4-774c-4c83-8360-01427e17a33a",
  "status": "OK"
}

Receive notification

For each SMS sent, you can receive a notification. For this you'll need a webhook configured to receive these notifications. By sending the URL of this webhook along with the request, the notification will be delivered on this URL, where you can process this. This applies for single SMS and for bulk SMS. With bulk SMS you can set this up to:

  • receive all notifications in the bulk request on a single URL,
  • receive a notification for one or more recipients on a specific URL,
  • receive a notification for one or more messages on a specific URL,
  • or make a combination of above options; receive notifications on a specific URL for one or more messages, one or more recipients and still use a general URL for the remainder of the messages.

Receiving notifications is free of charge.

Here are a couple of examples of a payload for the request with SMS's being send with the setup of a webhook.

^^One webhook for one or all SMS^^
{
                "sender": "KPN",
                "webhook_url": "https://hostname/path",
                "messages": [{
                              "content": "Hi from KPN!",
                              "mobile_number": "+316xxxxxxxx"
                }],
}

^^Webhooks for each SMS^^
{
                "sender": "KPN",
                "messages": [{
                              "content": "Hi from KPN!",
                              "mobile_number": "+316xxxxxxxx",
                              "webhook_url": "https://hostname1/path1"
                },{
                              "content": "Hi from KPN!",
                              "mobile_number": "+316xxxxxxxx",
                              "webhook_url": "https://hostname2/path2"
                }],
}

^^A mix – one SMS with a dedicated webhook and others with a general webhook.^^
{
                "sender": "KPN",
                "webhook_url": "https://hostname/path",
                "messages": [{
                              "content": "Hi from KPN!",
                              "mobile_number": "+316xxxxxxxx"
                },{
                              "content": "Another Hi from KPN!",
                              "mobile_number": "+316xxxxxxxx",
                              "webhook_url": "https://hostname2/path2"
                },{
                              "content": "Yet another hi from KPN!",
                              "mobile_number": "+316xxxxxxxx"
                }],
}

Dedicated webhook(s) have a priority over the general one.

On the webhook you are going to receive a json message. The structure is as follows:

^^Notification received example^^
{
  "Fields": {
    "Status": {
      "StatusDateTime": "2021-12-02T13:25:34Z",
      "StatusValue": "1",
      "StatusCode": "Delivered"
    },
    "Sender": "KPN",
    "WebhookURL": "https://hostname/path",
    "Message": "Hi There",
    "RecipientPhonenumber": "+316xxxxxxxx",
    "CustomerId": "email@domain.com"
  },
  "DLRID": "9F7742AD353FSGS2345SDCDSV45C02",
  "Service": "Sms",
  "MessageType": "SmsDeliveryReport",
  "MessageID": "4C0FWFWE86EE492ABCD34534122hJKHKHFDW"
}

The possible values of statusValues - StatusCodes are:

  • 1 - Delivered
  • 2 - Sent
  • 3 - New
  • 4 - Failed
  • 5 - TechnicalError


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 website 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 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 if the Access-Control-Allow-Credentials value is true. Boolean.
access-control-allow-origin Indicates whether the response can be shared with requesting code 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